# HG changeset patch # User markus schnalke # Date 1340566943 -7200 # Node ID 2b094b8fb42241342f42e8f3814639a6d534ea09 # Parent dd5620bf8659e8a47a73eb6dff4419408351ef51 Rework of existing text. diff -r dd5620bf8659 -r 2b094b8fb422 discussion.roff --- a/discussion.roff Sat Jun 23 23:53:52 2012 +0200 +++ b/discussion.roff Sun Jun 24 21:42:23 2012 +0200 @@ -682,7 +682,7 @@ .CW --with-editor=EDITOR .CW --with-pager=PAGER were used to specify the default editor and pager at configure time. -Doing so at configure time made sense in the Eighties, +Doing so at configure time made sense in the eighties, when the set of available editors and pagers varied much across different systems. Today, the situation is more homogeneous. @@ -1066,7 +1066,7 @@ A change early in the project was the complete transition from the single draft message to the draft folder facility. .Ci 337338b404931f06f0db2119c9e145e8ca5a9860 -The draft folder facility was introduced in the mid-Eighties, when +The draft folder facility was introduced in the mid-eighties, when Rose and Romine called it a ``relatively new feature''. .[ rose romine real work @@ -1584,7 +1584,7 @@ ``Lists messages in reverse order with the `\-reverse' switch. This should be considered a bug.'' by Romine in the documentation. The question remains why neither Rose and Romine had fixed this -bug in the Eighties when they wrote these comments nor has anyone +bug in the eighties when they wrote these comments nor has anyone thereafter. @@ -1638,9 +1638,9 @@ .H1 "Modernizing .P -The code base of mmh originates from the late Seventies. -Through the Eighties, extensive work had been done on it. -In the Nineties, it had been partly reorganized and extended. +The code base of mmh originates from the late seventies. +Through the eighties, extensive work had been done on it. +In the nineties, it was partly reorganized and extended. Relicts from each decade have gathered in the code base. My goal was to modernize the code base. @@ -1652,7 +1652,7 @@ .H2 "Code Relicts .P -My position to drop obsolete functionality of mmh to remove old code +My position to drop obsolete functions of mmh, in order to remove old code, is much more revolutional than the nmh community likes to have it. Working on an experimental version, I was able to quickly drop functionality I considered ancient. @@ -1682,20 +1682,23 @@ The decision to drop a feature was based on literature research and careful thinking, but whether having had contact to this particular feature within my own computer life served as a rule of thumb. -My reasons are always made clean in the commit message for the -version control system. +Always, I explained my reasons in the commit messages +in the version control system. Hence, others can comprehend my view and argue for undoing the change if I have missed an important aspect. +I was quick in dropping parts. +I rather re-included falsely dropped parts than going a slower pace. +Mmh is experimental work; it required tough decisions. .U3 "Forking .P -In being a tool chest, MH creates many processes. +Being a tool chest, MH creates many processes. In earlier times .Fu fork() had been an expensive system call, because the process's image needed to be duplicated completely at once. -This was especially painfull in the common case when the image gets +This was especially painful in the common case when the image gets replaced by a call to .Fu exec() right after having forked the child process. @@ -1731,54 +1734,59 @@ .Fu vfork() with calls to .Fu fork() . +.Ci 40821f5c1316e9205a08375e7075909cc9968e7d .P Related to the costs of .Fu fork() is the probability of its success. -In the Eighties on heavy loaded systems, calls to +In the eighties, on heavy loaded systems, calls to .Fu fork() were prone to failure. Hence, many of the .Fu fork() calls in the code were wrapped into loops to retry the .Fu fork() -several times, for higher changes to succeed, eventually. -On modern systems, failing calls to +several times, to increase the changes to succeed, eventually. +On modern systems, a failing .Fu fork() -are unusual. +call is unusual. Hence, in the rare case when .Fu fork() fails, mmh programs simply abort. +.Ci 5fbf37ee68e018998ada61eeab73e035b26834b6 -.U3 "Obsolete Header Fields +.U3 "Header Fields .BU The .Hd Encrypted header field was introduced by RFC\|822, -but already marked legacy in RFC\|2822. -OpenPGP provides the basis for standardized exchange of encrypted +but already marked as legacy in RFC\|2822. +Today, OpenPGP provides the basis for standardized exchange of encrypted messages [RFC\|4880, RFC\|3156]. -The support for +Hence, the support for .Hd Encrypted header fields is removed in mmh. +.Ci 064527f7b57ab050e5af13e15ad99aeeab125857 .BU Native support for .Hd Face header fields has been removed, as well. +.Ci 8e5be81f784682822f5e868c1bf3c8624682bd23 This feature is similar to the .Hd X-Face header field in its intent, but takes a different approach to store the image. Instead of encoding the image data directly into the header field, -the it contains the hostname and UDP port where the image -date could be retrieved. -There is even a third system, invented in 2005. -Although it re-uses the +it contains the hostname and UDP port where the image +date can be retrieved. +There exists even a third Face system, +which is the successor of +.Hd X-Face , +although it re-uses the .Hd Face -header field, it is the successor of -.Hd X-Face -with support for colored PNG images. +header field. +It was invented in 2005 and supports colored PNG images. None of the Face systems described here is popular today. Hence, mmh has no direct support for them. .BU @@ -1792,18 +1800,19 @@ end-to-end relationship is the use of digital cryptography. .\" XXX (RFCs FIXME). On the other hand, transfer protocols should detect corruption during -each transmission. The TCP includes a checksum field therefore. +the transmission. +The TCP includes a checksum field therefore. These two approaches in combinations render the .Hd Content-MD5 header field superfluous. -The nmh-workers mailing list archive contains about 4\|200 messages, -ranging from 1992 until today. -Not a single one had a +Not a single one out of 4\|200 messages from two decades +in an nmh-workers mailing list archive contains a .Hd Content-MD5 header field. Neither did any of the 60\|000 messages in my personal mail storage. Removing the support for this header field, removed the last place where MD5 computation was needed. +.Ci 31dc797eb5178970d68962ca8939da3fd9a8efda Hence, the MD5 code could be removed as well. Over 500 lines of code vanished by this one change. @@ -1814,21 +1823,24 @@ but uses a different message delimiter (`\fL^A^A^A^A\fP' instead of `\fLFrom\0\fP'). Mbox is the de-facto standard maildrop format on Unix, -whereas the MMDF maildrop format is hardly still known today. +whereas the MMDF maildrop format became forgotten. I did drop MMDF maildrop format support. +Mbox is the only packed mailbox format supported in mmh. .P -The simplifications within the code were only moderate. -Switches could be removed from -.L packf +The simplifications within the code were moderate. +Mainly, the reading and writing of MMDF mailbox files was removed. +But also, switches of +.Pn packf and -.L rcvpack , -which generate packed mailboxes. -Only one packed mailbox format remained: mbox. -The more important changes affected the equally named mail parsing -routine in -.Fn sbr/m_getfld.c . -The MMDF code had been removed there, but as now only one packed mailbox -format is left, further code structure simplifications may be possible. +.Pn rcvpack +could be removed. +.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0 +In the message parsing function +.Fn sbr/m_getfld.c , +knowledge of MMDF packed mail boxes was removed. +.Ci 684ec30d81e1223a282764452f4902ed4ad1c754 +Further code structure simplifications may be possible there, +because only one single packed mailbox format is left to be supported. I have not worked on them yet because .Fu m_getfld() is heavily optimized and thus dangerous to touch. @@ -1836,7 +1848,7 @@ too high. .\" XXX: move somewhere else This problem is know to the developers of nmh, too. -They also avoid touching this minefield if possible. +They also avoid touching this minefield. .U3 "Prompter's Control Keys @@ -1869,28 +1881,30 @@ .Ci 0bd9750710cdbab80cfb4036dd87af20afe1552f . -.U3 "Hardcopy terminal support +.U3 "Hardcopy Terminal Support .P -More of a funny anecdote is a check for printing to a -hardcopy terminal that remained in the code until Spring 2012, -when I finally removed it +More of a funny anecdote is a check for being connected to a +hardcopy terminal. +It remained in the code until Spring 2012, when I finally removed it .Ci b7764c4a6b71d37918a97594d866258f154017ca . -I surely would be very happy to see such a terminal in action, -maybe actually being able to work on it, but I fear my chances are null. +I would be truly happy to see such a terminal in action today, +maybe even being able to work on it. +But I fear my chances are null. .P -The check only prevented a pager to be placed between the outputting +The check only prevented a pager to be placed between the printing program (\c .Pn mhl ) and the terminal. -In nmh, this could have been ensured with the +In nmh, this could have been ensured statically with the .Sw -nomoreproc -at the command line statically, too. -In mmh, set the profile entry +at the command line, too. +In mmh, seting the profile entry .Pe Pager or the environment variable .Ev PAGER to -.Pn cat . +.Pn cat +does the job. @@ -1899,7 +1913,7 @@ .P The mind model of email attachments is unrelated to MIME. Although the MIME RFCs (2045 through 2049) define the technical -requirements for having attachments, they do not mention the the word +requirements for having attachments, they do not mention the word ``attachment''. Instead of attachments, MIME talks about ``multi-part message bodies'' [RFC\|2045], a more general concept. @@ -1909,7 +1923,7 @@ [RFC\|2046]. MIME keeps its descriptions generic; it does not imply specific usage models. -In email one usage model became prevalent: attachments. +One usage model became prevalent: attachments. The idea is having a main text document with files of arbitrary kind attached to it. In MIME terms, this is a multi-part message having a text part first @@ -1918,9 +1932,10 @@ MH's MIME support is a direct implementation of the RFCs. The perception of the topic described in the RFCs is clearly visible in MH's implementation. -Thus, MH had all the MIME features but no idea of attachments. -Today, however, users don't need all the MIME features but they want -convenient attachment handling. +In result, MH had all the MIME features but no idea of attachments. +But users don't need all the MIME features, +they want convenient attachment handling. + .U3 "Composing MIME Messages .P