docs/master: discussion.roff comparison

comparison discussion.roff @ 109:2b094b8fb422

Rework of existing text.

author	markus schnalke <meillo@marmaro.de>
date	Sun, 24 Jun 2012 21:42:23 +0200
parents	dd5620bf8659
children	4c0f13b1e0e8

comparison

equal deleted inserted replaced

-:dd5620bf8659
+:2b094b8fb422
 .P
 The two configure options
 .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.
 The programs
 .Pn vi
 .U3 "Draft Folder Facility
 .P
 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
 .]
 Since then, the facility had existed but was deactivated by default.
 ``\-[no]reverse under #ifdef BERK (I really HATE this)''
 by Rose and
 ``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.
 .ig
 .H1 "Modernizing
 .P
-The code base of mmh originates from the late Seventies.
+The code base of mmh originates from the late seventies.
-Through the Eighties, extensive work had been done on it.
+Through the eighties, extensive work had been done on it.
-In the Nineties, it had been partly reorganized and extended.
+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.
 .P
 FIXME functional aspect only here
 FIXME ref to `code style' for non-functional aspects.
 .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.
 The need for consensus with peers would have slowed this process down.
 Without the need to justify my decisions, I was able to rush forward.
 I simply dropped the cruft.
 .P
 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
+Always, I explained my reasons in the commit messages
-version control system.
+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.
 The
 .Fu vfork()
 .]
 I replaced all calls to
 .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.
+several times, to increase the changes to succeed, eventually.
-On modern systems, failing calls to
+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.
+but already marked as legacy in RFC\|2822.
-OpenPGP provides the basis for standardized exchange of encrypted
+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
+it contains the hostname and UDP port where the image
-date could be retrieved.
+date can be retrieved.
-There is even a third system, invented in 2005.
+There exists even a third Face system,
-Although it re-uses the
+which is the successor of
+.Hd X-Face ,
+although it re-uses the
 .Hd Face
-header field, it is the successor of
+header field.
-.Hd X-Face
+It was invented in 2005 and supports colored PNG images.
-with support for colored PNG images.
 None of the Face systems described here is popular today.
 Hence, mmh has no direct support for them.
 .BU
 The
 .Hd Content-MD5
 [RFC\|1864].
 The proper approach to verify content integrity in an
 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,
+Not a single one out of 4\|200 messages from two decades
-ranging from 1992 until today.
+in an nmh-workers mailing list archive contains a
-Not a single one had 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.
 .U3 "MMDF maildrop support
 .P
 This type of format is conceptionally similar to the mbox format,
 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.
-.P
+Mbox is the only packed mailbox format supported in mmh.
-The simplifications within the code were only moderate.
+.P
-Switches could be removed from
+The simplifications within the code were moderate.
-.L packf
+Mainly, the reading and writing of MMDF mailbox files was removed.
-and
+But also, switches of
-.L rcvpack ,
+.Pn packf
-which generate packed mailboxes.
+and
-Only one packed mailbox format remained: mbox.
+.Pn rcvpack
-The more important changes affected the equally named mail parsing
+could be removed.
-routine in
+.Ci 3916ab66ad5d183705ac12357621ea8661afd3c0
-.Fn sbr/m_getfld.c .
+In the message parsing function
-The MMDF code had been removed there, but as now only one packed mailbox
+.Fn sbr/m_getfld.c ,
-format is left, further code structure simplifications may be possible.
+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.
 The risk of damaging the intricate workings of the optimized code is
 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
 .P
 The program
 .Pn stty .
 The switches are removed now
 .Ci 0bd9750710cdbab80cfb4036dd87af20afe1552f .
-.U3 "Hardcopy terminal support
+.U3 "Hardcopy Terminal Support
 .P
-More of a funny anecdote is a check for printing to a
+More of a funny anecdote is a check for being connected to a
-hardcopy terminal that remained in the code until Spring 2012,
+hardcopy terminal.
-when I finally removed it
+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,
+I would be truly happy to see such a terminal in action today,
-maybe actually being able to work on it, but I fear my chances are null.
+maybe even being able to work on it.
-.P
+But I fear my chances are null.
-The check only prevented a pager to be placed between the outputting
+.P
+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.
+at the command line, too.
-In mmh, set the profile entry
+In mmh, seting the profile entry
 .Pe Pager
 or the environment variable
 .Ev PAGER
 to
-.Pn cat .
+.Pn cat
+does the job.
 .H2 "Attachments
 .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.
 Multi-part messages are messages
 ``in which one or more different
 sets of data are combined in a single body''
 [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
 and parts of arbitray type following.
 .P
 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.
+In result, MH had all the MIME features but no idea of attachments.
-Today, however, users don't need all the MIME features but they want
+But users don't need all the MIME features,
-convenient attachment handling.
+they want convenient attachment handling.
 .U3 "Composing MIME Messages
 .P
 In order to improve the situation on the message composing side,
 Jon Steinhart had added an attachment system to nmh in 2002.

Mercurial > docs > master

comparison discussion.roff @ 109:2b094b8fb422