docs/master: discussion.roff comparison

comparison discussion.roff @ 159:8b411125645d

Corrections and improvements by Kate, Phil, Matou, Michi, Lydi.

author	markus schnalke <meillo@marmaro.de>
date	Mon, 09 Jul 2012 11:16:30 +0200
parents	0cce17978f0a
children	5c01017be420

comparison

equal deleted inserted replaced

-:a6dc418ab0a4
+:8b411125645d
 The community around nmh has a similar understanding.
 In fundamental difference, mmh shall be a MUA only.
 I believe that the development of all-in-one mail systems is obsolete.
 Today, email is too complex to be fully covered by single projects.
 Such a project won't be able to excel in all aspects.
-Instead, the aspects of email should be covered my multiple projects,
+Instead, the aspects of email should be covered by multiple projects,
 which then can be combined to form a complete system.
 Excellent implementations for the various aspects of email exist already.
 Just to name three examples: Postfix is a specialized MTA,
+.\" XXX homepages verlinken
 Procmail is a specialized MDA, and Fetchmail is a specialized MRA.
 I believe that it is best to use such specialized tools instead of
 providing the same function again as a side-component in the project.
 .P
 Doing something well, requires to focus on a small set of specific aspects.
 Removing the mail transfer facilities had been the first work task
 in the mmh project.
 .P
 Focusing on one mail agent role only is motivated by Eric Allman's
 experience with Sendmail.
-He identified limiting Sendmail the MTA task had be one reason for
+He identified the limitation of Sendmail to the MTA task as one reason for
 its success:
 .[ [
 costales sendmail
 .], p. xviii]
 .QS
 This was a departure of the dominant through of the time,
 in which routing logic, local delivery, and often the network code
 were incorporated directly into the user agents.
 .QE
 .P
-In mmh, the Mail Submission Agent (MSA) is called
+In nmh, the Mail Submission Agent (MSA) is called
 \fIMessage Transfer Service\fP (MTS).
 This facility, implemented by the
 .Pn post
 command, established network connections and spoke SMTP to submit
-messages for relay to the outside world.
+messages to be relayed to the outside world.
 The changes in email demanded changes in this part of nmh too.
 Encryption and authentication for network connections
 needed to be supported, hence TLS and SASL were introduced into nmh.
 This added complexity to nmh without improving it in its core functions.
 Also, keeping up with recent developments in the field of
 to be added soon, too, and likewise for any other changes in mail transfer.
 Not so for mmh because it has dropped the support for retrieving mail
 from remote locations.
 .Ci ab7b48411962d26439f92f35ed084d3d6275459c
 Instead, it depends on an external tool to cover this task.
-In mmh exist two paths for messages to enter mmh's mail storage:
+In mmh, two paths exist for messages to enter mmh's mail storage:
 (1) Mail can be incorporated with
 .Pn inc
 from the system maildrop, or (2) with
 .Pn rcvstore
 by reading them, one at a time, from the standard input.
 mail system to being a MUA only.
 Now, of course, mmh depends on third-party software.
 An external MSA is required to transfer mail to the outside world;
 an external MRA is required to retrieve mail from remote machines.
 There exist excellent implementations of such software,
-which do this specific task likely better than the internal
+which likely are superior than the internal version.
-versions had done it.
+Additionally, the best suiting programs can be freely chosen.
-Also, the best suiting programs can be freely chosen.
 .P
 As it had already been possible to use an external MSA or MRA,
 why not keep the internal version for convenience?
+.\" XXX ueberleitung
 The question whether there is sense in having a fall-back pager in all
 the command line tools, for the cases when
 .Pn more
 or
 .Pn less
 There is no more need to concern with changes in network transfer.
 This independence is received by depending on an external program
 that covers the field.
 Today, this is a reasonable exchange.
 .P
+.\" XXX ueberleitung ???
 Functionality can be added in three different ways:
 .BU
 Implementing the function originally in the project.
 .BU
 Depending on a library that provides the function.
 .BU
 Depending on a program that provides the function.
 .P
-Whereas adding the function originally to the project increases the
+.\" XXX Rework sentence
+While adding the function originally to the project increases the
 code size most and requires most maintenance and development work,
 it makes the project most independent of other software.
 Using libraries or external programs require less maintenance work
 but introduces dependencies on external software.
 Programs have the smallest interfaces and provide the best separation
 but possibly limit the information exchange.
 External libraries are stronger connected than external programs,
 thus information can be exchanged more flexible.
 Adding code to a project increases maintenance work.
 .\" XXX ref
-Implementing complex functions originally in the project adds
+Implementing complex functions in the project itself adds
 a lot of code.
 This should be avoided if possible.
 Hence, the dependencies only change in kind, not in their existence.
 In mmh, library dependencies on
 .Pn libsasl2
 and
 .Pn libcrypto /\c
 .Pn libssl
-were treated against program dependencies on an MSA and an MRA.
+were traded against program dependencies on an MSA and an MRA.
-This also meant treating build-time dependencies against run-time
+This also meant trading build-time dependencies against run-time
 dependencies.
 Besides program dependencies providing the stronger separation
 and being more flexible, they also allowed
 over 6\|000 lines of code to be removed from mmh.
 This made mmh's code base about 12\|% smaller.
 .P
 Users of MH should not have problems to set up an external MSA and MRA.
 Also, the popular MSAs and MRAs have large communities and a lot
 of documentation available.
 Choices for MSAs range from full-featured MTAs like
+.\" XXX refs
 .I Postfix
 over mid-size MTAs like
 .I masqmail
 and
 .I dma
 .BU
 .Pn rcvtty
 was removed
 .Ci 14767c94b3827be7c867196467ed7aea5f6f49b0
 because its use case of writing to the user's terminal
-on receiving of mail is obsolete.
+on receival of mail is obsolete.
 If users like to be informed of new mail, the shell's
 .Ev MAILPATH
 variable or graphical notifications are technically more appealing.
 Writing directly to terminals is hardly ever wanted today.
 If though one wants to have it this way, the standard tool
 .VS
 scan -file - | write `id -un`
 VE
 .BU
 .Pn viamail
+.\" XXX was macht viamail
 was removed
 .Ci eda72d6a7a7c20ff123043fb7f19c509ea01f932
 when the new attachment system was activated, because
 .Pn forw
 could then cover the task itself.
 was rewritten as a shell script wrapper around
 .Pn forw .
 .Ci 0e82199cf3c991a173e0ac8aa776efdb3ded61e6
 .BU
 .Pn msgchk
+.\" XXX was macht msgchk
 was removed
 .Ci bb9360ead7eb7a3fedcce2eeedfc660014e41dbe ,
 because it lost its use case when POP support was removed.
 A call to
 .Pn msgchk
 .Pn msh
 was removed
 .Ci 916690191222433a6923a4be54b0d8f6ac01bd02
 because the tool was in conflict with the philosophy of MH.
 It provided an interactive shell to access the features of MH,
-but it wasn't just a shell, tailored to the needs of mail handling.
+but it wasn't just a shell tailored to the needs of mail handling.
 Instead it was one large program that had several MH tools built in.
 This conflicts with the major feature of MH of being a tool chest.
 .Pn msh 's
-main use case had been accessing Bulletin Boards, which have seized to
+main use case had been accessing Bulletin Boards, which have ceased to
 be popular.
 .P
 Removing
 .Pn msh ,
 together with the truly archaic code relicts
 is not split off.
 I defer the decision over
 .Pn slocal
 in need for deeper investigation.
 In the meanwhile, it remains part of mmh.
-That does not hurt because
+However, its continued existence is not significant because
 .Pn slocal
 is unrelated to the rest of the project.
 .H2 "Displaying Messages
 .Id mhshow
 .P
 Since the very beginning, already in the first concept paper,
+.\" XXX ref!!!
 .Pn show
 had been MH's message display program.
 .Pn show
 mapped message numbers and sequences to files and invoked
 .Pn mhl
 .P
 Today, non-MIME messages are rather seen to be a special case of
 MIME messages, although it is the other way round.
 As
 .Pn mhshow
-had already be able to display non-MIME messages, it appeared natural
+had already been able to display non-MIME messages, it appeared natural
 to drop
 .Pn show
 in favor of using
 .Pn mhshow
 exclusively.
 .Cf mhshow )
 Once the tools behaved more alike, the replacing appeared to be
 even more natural.
 Today, mmh's new
 .Pn show
-became the one single message display program again, with the difference
+has become the one single message display program once more,
+with the difference
 that today it handles MIME messages as well as non-MIME messages.
 The outcome of the transition is one program less to maintain,
 no second display program for users to deal with,
 and less system complexity.
 .P
 Still, removing the old
 .Pn show
 hurts in one regard: It had been such a simple program.
-Its lean elegance is missing to the new
+Its lean elegance is missing from the new
-.Pn show .
+.Pn show ,
-But there is no chance;
+.\" XXX
-supporting MIME demands for higher essential complexity.
+however there is no alternative;
+supporting MIME demands higher essential complexity.
 .ig
 XXX
 Consider including text on scan listings here
 Customization is a double-edged sword.
 It allows better suiting setups, but not for free.
 There is the cost of code complexity to be able to customize.
 There is the cost of less tested setups, because there are
 more possible setups and especially corner-cases.
-And, there is the cost of choice itself.
+Additionally, there is the cost of choice itself.
 The code complexity directly affects the developers.
 Less tested code affects both, users and developers.
-The problem of choice affects the users, for once by having to
+The problem of choice affects the users, for once by having to choose,
-choose, but also by more complex interfaces that require more documentation.
+but also by more complex interfaces that require more documentation.
-Whenever options add little advantages, they should be considered for
+Whenever options add few advantages but increase the complexity of the
-removal.
+system, they should be considered for removal.
 I have reduced the number of project-specific configure options from
 fifteen to three.
 .U3 "Mail Transfer Facilities
 .P
 The switches
 .Sw --with-tls
 and
 .Sw --with-cyrus-sasl
 had activated the support for transfer encryption and authentication.
+.\" XXX cf
+.\" XXX gruende kurz wiederholen
 This is not needed anymore.
 .Ci fecd5d34f65597a4dfa16aeabea7d74b191532c3
 .Ci 156d35f6425bea4c1ed3c4c79783dc613379c65b
 .P
+.\" XXX cf
+.\" XXX ``For the same reason ...''
 The configure switch
 .Sw --enable-pop
 activated the message retrieval facility.
 The code area that would be conditionally compiled in for TLS and SASL
 support had been small.
 The conditionally compiled code area for POP support had been much larger.
 Whereas the code base changes would only slightly change on toggling
 TLS or SASL support, it changed much on toggling POP support.
 The changes in the code base could hardly be overviewed.
-By having POP support togglable a second code base had been created,
+By having POP support togglable, a second code base had been created,
 one that needed to be tested.
 This situation is basically similar for the conditional TLS and SASL
 code, but there the changes are minor and can yet be overviewed.
 Still, conditional compilation of a code base creates variations
 of the original program.
 .Sw --with-mts
 defined the default transport service, either
 .Ar smtp
 or
 .Ar sendmail .
+.\" XXX naechster Satz ganz raus?
 In mmh this fixed to
 .Ar sendmail .
 .Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
 With
 .Sw --with-smtpservers
 .U3 "Backup Prefix
 .P
 The backup prefix is the string that was prepended to message
 filenames to tag them as deleted.
 By default it had been the comma character `\f(CW,\fP'.
+.\" XXX Zeitlich ordnen
 In July 2000, Kimmo Suominen introduced
 the configure option
 .Sw --with-hash-backup
 to change the default to the hash symbol `\f(CW#\fP'.
 The choice was probably personal preference, because first, the
 .Cl "rm ./#13 ./#15"
 needs to be used.
 Using the hash as backup prefix can be seen as a precaution against
 data loss.
 .P
-I removed the configure option but added the profile entry
+First, I removed the configure option but added the profile entry
 .Pe backup-prefix ,
 which allows to specify an arbitrary string as backup prefix.
 .Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086
 Profile entries are the common method to change mmh's behavior.
 This change did not remove the choice but moved it to a location where
 .I ndbm
 vanished and 120 lines of complex autoconf code could be saved.
 .Ci ecd6d6a20cb7a1507e3a20d6c4cb3a1cf14c6bbf
 The change removed functionality too, but that is minor to the
 improvement by dropping the dependency and the complex autoconf code.
+.\" XXX argument: slocal ist sowieso nicht teil vom mmh kern
 .U3 "mh-e Support
 .P
 The configure option
 .Sw --disable-mhe
 .Sw --disable-mhe
 configure option was removed
 .Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643
 Removing the option removed a second code setup that would have
 needed to be tested.
+.\" XXX datum?
 This change was first done in nmh and thereafter merged into mmh.
 .P
 The interface changes in mmh require mh-e to be adjusted in order
 to be able to use mmh as back-end.
 This will require minor changes to mh-e, but removing the
 motivated by the fact that
 .Pn spost
 hadn't supported it already.
 .Ci 2abae0bfd0ad5bf898461e50aa4b466d641f23d9
 Username extensions are possible in mmh, but less convenient to use.
+.\" XXX covered by next paragraph
 .\" XXX format file %(getenv USERNAME_EXTENSION)
 .P
 The
 .I draft_from
 masquerading type instructed
 For example:
 .Cl "-truncate" .
 Every program in mmh has two generic switches:
 .Sw -help ,
 to print a short message on how to use the program, and
-.Sw -Version ,
+.Sw -Version
-to tell what version of mmh the program belongs to.
+[sic!], to tell what version of mmh the program belongs to.
 .P
 Switches change the behavior of programs.
 Programs that do one thing in one way require no switches.
 In most cases, doing something in exactly one way is too limiting.
 If there is basically one task to accomplish, but it should be done
 have remained in mmh's
 .Pn send .
 (These numbers include two generic switches, help and version.)
 .P
 The figure displays the number of switches for each of the tools
-that is available in both, nmh and mmh.
+that is available in both nmh and mmh.
 The tools are sorted by the number of switches they had in nmh.
 Visible and hidden switches were counted,
 but not the generic help and version switches.
 Whereas in the beginning of the project, the average tool had 11 switches,
 now it has no more than 5 \(en only half as many.
 .Pn send .
 .Ci 337338b404931f06f0db2119c9e145e8ca5a9860
 The only flexibility removed with this change is having multiple
 draft folders within one profile.
 I consider this a theoretical problem only.
-In the same go, the
+At the same time, the
 .Sw -draft
 switch of
 .Pn anno ,
 .Pn refile ,
 and
 .Pn send
 was removed.
-The special-casing of `the' draft message became irrelevant after
+The special treatment of \fIthe\fP draft message became irrelevant after
 the rework of the draft system.
-(df. Sec.
+(cf. Sec.
 .Cf draft-folder )
 Equally,
 .Pn comp
 lost its
 .Sw -file
 .Pn mhbuild
 and
 .Pn mhlist
 were removed, doing real size calculations always now
 .Ci 8d8f1c3abc586c005c904e52c4adbfe694d2201c ,
-as
+as nmh's
+.Mp mhbuild (1)
+man page states
 ``This provides an accurate count at the expense of a small delay.''
 This small delay is not noticable on modern systems.
 .P
 The
 .Sw -[no]check
 and
 .Sw -wcache
 switches was completely removed.
 .Ci d1fefd9f614e4dc3cda16da6c69133c1b2005269
 External MIME parts are rare today, having a caching facility
-for them is appears to be unnecessary.
+for them appears to be unnecessary.
 .P
 In pre-MIME times,
 .Pn mhl
 had covered many tasks that are part of MIME handling today.
 Therefore,
 .U3 "Header Printing
 .P
 .Pn folder 's
 data output is self-explaining enough that
-displaying the header line makes few sense.
+displaying the header line makes little sense.
 Hence, the
 .Sw -[no]header
 switch was removed and headers are never printed.
 .Ci 601cc73d1fa05ce96faa728f036d6c51b91701c7
 .P
 was removed, but it can now be replaced by specifying
 .Sw -editor
 with an empty argument.
 .Ci 75fca31a5b9d5c1a99c74ab14c94438d8852fba9
 (Specifying
-.Cl "-editor true
+.Cl "-editor /bin/true
 is nearly the same, only differing by the previous editor being set.)
 .P
 The more important change is the removal of the
 .Sw -nowhatnowproc
 switch.
 .P
 Effectively, the
 .Sw -nowhatnowproc
 switch creates only a draft message.
 As
-.Cl "-whatnowproc true
+.Cl "-whatnowproc /bin/true
 causes the same behavior, the
 .Sw -nowhatnowproc
 switch was removed for being redundant.
 Likely, the
 .Sw -nowhatnowproc
 .Sw -[no]bell
 .Ci e11983f44e59d8de236affa5b0d0d3067c192e24 )
 nor page the output itself (\c
 .Sw -length
 .Ci 5b9d883db0318ed2b84bb82dee880d7381f99188 ).
+.\" XXX Ref
 Generally, the pager to use is no longer specified with the
 .Sw -[no]moreproc
 command line switches for
 .Pn mhl
 and
 is a bug fix, supported by the comments
 ``\-[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.
+.\" XXX Ref: welche datei genau.
 The question remains why neither Rose and Romine had fixed this
 bug in the eighties when they wrote these comments nor has anyone
 thereafter.
 .\" --------------------------------------------------------------
 .H1 "Modernizing
 .P
-In the over thirty years of MH's existence, its code base was
+In the more thirty years of MH's existence, its code base was
-extended more and more.
+increasingly extended.
 New features entered the project and became alternatives to the
 existing behavior.
 Relicts from several decades have gathered in the code base,
 but seldom obsolete features were dropped.
 This section describes the removing of old code
 .Cf code-style .
 .H2 "Code Relicts
 .P
-My position to drop obsolete functions of mmh, in order to remove old code,
+My position regarding the removal of obsolete functions of mmh,
-is much more revolutional than the nmh community likes to have it.
+.\" XXX ``in order to remove old code,''
-Working on an experimental version, I was able to quickly drop
+is much more revolutional than the nmh community appreciates.
+Working on an experimental version, I was quickly able to 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.
 In December 2011, Paul Vixie motivated the nmh developers to just
+.\" XXX ugs
 do the work:
 .[
 paul vixie edginess nmh-workers
 .]
 .QS
 let's push forward, aggressively.
 .QE
 .LP
 I did so already in the months before.
 I pushed forward.
+.\" XXX semicolon ?
 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
+careful thinking, but whether having had contact with this particular
 feature within my own computer life served as a rule of thumb.
-Always, I explained my reasons in the commit messages
+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.
+I rather re-included falsely dropped parts than going at a slower pace.
 Mmh is experimental work; it required tough decisions.
+.\" XXX ``exp. work'' schon oft gesagt
 .U3 "Forking
 .P
 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.
+to be completely duplicated at once.
-This was especially painful in the common case when the image gets
+This expensive work was especially unnecessary in the commonly occuring
-replaced by a call to
+case wherein the image is replaced by a call to
 .Fu exec()
 right after having forked the child process.
 The
 .Fu vfork()
 system call was invented to speed up this particular case.
 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, to increase the changes to succeed, eventually.
+several times, to increase the chances to succeed, eventually.
 On modern systems, a failing
 .Fu fork()
 call is unusual.
 Hence, in the rare case when
 .Fu fork()
 Hence, the support for
 .Hd Encrypted
 header fields is removed in mmh.
 .Ci 064527f7b57ab050e5af13e15ad99aeeab125857
 .BU
-Native support for
+The 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,
 it contains the hostname and UDP port where the image
 date can be retrieved.
-There exists even a third Face system,
+There is even a third Face system,
 which is the successor of
 .Hd X-Face ,
 although it re-uses the
 .Hd Face
 header field.
 .P
 This type of format is conceptionally similar to the mbox format,
 but uses a different message delimiter (`\fL\\1\\1\\1\\1\fP',
 commonly written as `\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 became forgotten.
+whereas the MMDF maildrop format is now forgotten.
-I did drop MMDF maildrop format support.
+By dropping the MMDF maildrop format support,
-Mbox is the only packed mailbox format supported in mmh.
+mbox became the only packed mailbox format supported in mmh.
 .P
 The simplifications within the code were moderate.
 Mainly, the reading and writing of MMDF mailbox files was removed.
 But also, switches of
 .Pn packf
 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 known to the developers of nmh, too.
-They also avoid touching this minefield.
 .U3 "Prompter's Control Keys
 .P
 The program
 .U3 "Hardcopy Terminal Support
 .P
 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
+It remained in the code until spring 2012, when I finally removed it
 .Ci b7764c4a6b71d37918a97594d866258f154017ca .
-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 printing
 program (\c
 .Pn mhl )
 and the terminal.
 .Pe Pager
 or the environment variable
 .Ev PAGER
 to
 .Pn cat
-does the job.
+is sufficient.
 .H2 "Attachments
 and parts of arbitrary 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.
-In result, MH had all the MIME features but no idea of attachments.
+.\" XXX rewrite ``no idea''.
+As a 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
 .Ci 7480dbc14bc90f2d872d434205c0784704213252
 In the file
 .Fn docs/README-ATTACHMENTS ,
 he described his motivation to do so as such:
 .QS
-Although nmh contains the necessary functionality for MIME message handing,
+Although nmh contains the necessary functionality for MIME message
-the interface to this functionality is pretty obtuse.
+handing [sic!], the interface to this functionality is pretty obtuse.
 There's no way that I'm ever going to convince my partner to write
 .Pn mhbuild
 composition files!
 .QE
 .LP
 profile entry is used to specify
 the name of the attachment header field.
 It is pre-defined to
 .Hd Attach .
 .P
-To add an attachment to a draft, simply add an attachment header:
+To add an attachment to a draft, a header line needs to be added:
 .VS
 To: bob
 Subject: The file you wanted
 Attach: /path/to/the/file-bob-wanted
 --------
 anno -append -nodate -component Attach -text /path/to/attachment
 VE
 Drafts with attachment headers are converted to MIME automatically by
 .Pn send .
 The conversion to MIME is invisible to the user.
-The draft stored in the draft folder is always in source form, with
+The draft stored in the draft folder is always in source form with
 attachment headers.
 If the MIMEification fails, for instance because the file to attach
 is not accessible, the original draft is not changed.
 .P
 The attachment system handles the forwarding of messages, too.
 If the attachment header value starts with a plus character (`+'),
 like in
 .Cl "Attach: +bob 30 42" ,
-The given messages in the specified folder will be attached.
+the given messages in the specified folder will be attached.
 This allowed to simplify
 .Pn forw .
 .Ci f41f04cf4ceca7355232cf7413e59afafccc9550
 .P
 Closely related to attachments is non-ASCII text content,
 If the user did not call `mime', a broken message would be sent.
 Therefore, the
 .Pe automimeproc
 profile entry could be specified to have the `mime' command invoked
 automatically each time.
-Unfortunately, this approach conflicted with with attachment system
+Unfortunately, this approach conflicted with attachment system
 because the draft would already be in MIME format at the time
 when the attachment system wanted to MIMEify it.
 To use nmh's attachment system, `mime' must not be called at the
 WhatNow prompt and
 .Pe automimeproc
 Mmh's current solution is even more elaborate.
 Any necessary MIMEification is done automatically.
 There is no `mime' command at the WhatNow prompt anymore.
 The draft will be converted automatically to MIME when either an
 attachment header or non-ASCII text is present.
-Further more, the special meaning of the hash character (`#')
+Furthermore, the hash character (`#') is not special any more
-at line beginnings in the draft message is removed.
+at line beginnings in the draft message.
-Users need not at all deal with the whole topic.
+.\" XXX REF ?
+Users need not concern themselves with the whole topic at all.
 .P
 Although the new approach does not anymore support arbitrary MIME
 compositions directly, the full power of
 .Pn mhbuild
 can still be accessed.
 .Cl "edit mhbuild
 to convert it to MIME.
 Because the resulting draft does neither contain non-ASCII characters
 nor has it attachment headers, the attachment system will not touch it.
 .P
-The approach taken in mmh is tailored towards todays most common case:
+The approach taken in mmh is tailored towards today's most common case:
-a text part with possibly attachments.
+a text part, possibly with attachments.
-This case is simplified a lot for users.
+This case was simplified.
 .U3 "MIME Type Guessing
 .P
-The use of
+From the programmer's point of view, the use of
 .Pn mhbuild
-composition drafts had one notable advantage over attachment headers
+composition drafts had one notable advantage over attachment headers:
-from the programmer's point of view: The user provides the appropriate
+The user provides the appropriate MIME types for files to include.
-MIME types for files to include.
 The attachment system needs to find out the correct MIME type itself.
 This is a difficult task, yet it spares the user irritating work.
 Determining the correct MIME type of content is partly mechanical,
 partly intelligent work.
 Forcing the user to find out the correct MIME type,
 but not to be used by programs.
 It varies much.
 Nevertheless, modern versions of GNU
 .Pn file ,
 which is prevalent on the popular GNU/Linux systems,
-provides MIME type output in machine-readable form.
+provide MIME type output in machine-readable form.
 Although this solution is highly system-dependent,
 it solves the difficult problem well.
 On systems where GNU
 .Pn file ,
 version 5.04 or higher, is available it should be used.
 If no MIME type can be determined, text content gets sent as
 `text/plain' and anything else under the generic fall-back type
 `application/octet-stream'.
 It is not possible in mmh to override the automatic MIME type guessing
 for a specific file.
-To do so, the user would need to know in advance for which file
+To do so, either the user would need to know in advance for which file
-the automatic guessing does fail, or the system would require interaction.
+the automatic guessing fails, or the system would require interaction.
 I consider both cases impractical.
 The existing solution should be sufficient.
 If not, the user may always fall back to
 .Pn mhbuild
 composition drafts and ignore the attachment system.
 .Sw -force
 option.
 Users will likely need to invoke
 .Pn mhstore
 a second time with
-.Sw -force
+.Sw -force .
-then.
+Eventually, only the user can decide in the specific case.
-Eventually, only the user can decide in the concrete case.
 This requires interaction, which I like to avoid if possible.
 Appending a unique suffix to the filename is another bad option.
 For now, the behavior remains as it is.
 .P
 In mmh, only MIME parts of type message are special in
 .Pn mhstore 's
 .Sw -auto
 mode.
 Instead of storing message/rfc822 parts as files to disk,
 they are stored as messages into the current mail folder.
-The same applies to message/partial, only, the parts are reassembled
+The same applies to message/partial, although the parts are
-automatically before.
+automatically reassembled beforehand.
-Parts of type message/external-body are not automatically retrieved
+MIME parts of type message/external-body are not automatically retrieved
-anymore. Instead, Information on how to retrieve them is output.
+anymore.
+Instead, information on how to retrieve them is output.
 Not supporting this rare case saved nearly one thousand lines of code.
 .Ci 55e1d8c654ee0f7c45b9361ce34617983b454c32
 .\" XXX mention somewhere else too: (The profile entry `nmh-access-ftp'
 .\"     and sbr/ruserpass.c for reading ~/.netrc are gone now.)
-Not special anymore is `application/octet-stream; type=tar'.
+`application/octet-stream; type=tar' is not special anymore.
 Automatically extracting such MIME parts had been the dangerous part
 of the
 .Sw -auto
 mode.
 .Ci 94c80042eae3383c812d9552089953f9846b1bb6
 information on how to display the individual parts.
 I adjusted
 .Pn mhshow 's
 behavior to the modern view on the topic.
 .P
-Note that this section completely ignores the original
+One should note that this section completely ignores the original
 .Pn show
 program, because it was not capable to display MIME messages
 and is no longer part of mmh.
 Although
 .Pn mhshow
 was renamed to
 .Pn show
 in mmh, this section uses the name
 .Pn mhshow ,
 in order to avoid confusion.
+.\" XXX ref to other section
 .P
 In mmh, the basic idea is that
 .Pn mhshow
 should display a message in one single pager session.
 Therefore,

Mercurial > docs > master

comparison discussion.roff @ 159:8b411125645d