1.1 --- a/ch03.roff	Tue Jun 19 09:40:46 2012 +0200
     1.2 +++ b/ch03.roff	Tue Jun 19 10:54:50 2012 +0200
     1.3 @@ -10,7 +10,7 @@
     1.4  
     1.5  
     1.6  
     1.7 -.H1 "Stream-lining
     1.8 +.H1 "Stream-Lining
     1.9  
    1.10  .P
    1.11  MH had been considered an all-in-one system for mail handling.
    1.12 @@ -29,7 +29,7 @@
    1.13  .P
    1.14  Doing something well, requires to focus on a small set of specific aspects.
    1.15  Under the assumption that focused development produces better results
    1.16 -in the particular area, specialized projects will likely be superior
    1.17 +in the particular area, specialized projects will be superior
    1.18  in their field of focus.
    1.19  Hence, all-in-one mail system projects \(en no matter if monolithic
    1.20  or modular \(en will never be the best choice in any of the fields.
    1.21 @@ -47,21 +47,21 @@
    1.22  it has.
    1.23  .P
    1.24  In consequence, I believe that the available development resources
    1.25 -should be focused on the point where MH is most unique.
    1.26 +should focus on the point where MH is most unique.
    1.27  This is clearly the user interface \(en the MUA.
    1.28  Peripheral parts should be removed to stream-line mmh for the MUA task.
    1.29  
    1.30  
    1.31 -.H2 "Removal of the Mail Transfer Facilities
    1.32 +.H2 "Mail Transfer Facilities
    1.33  .P
    1.34  In contrast to nmh, which also provides mail submission and mail retrieval
    1.35  agents, mmh is a MUA only.
    1.36 -This general difference in the view on the character of nmh
    1.37 -initiated the development of mmh.
    1.38 +This general difference initiated the development of mmh.
    1.39  Removing the mail transfer facilities had been the first work task
    1.40  in the mmh project.
    1.41  .P
    1.42 -The MSA is called \fIMessage Transfer Service\fP (MTS) in nmh.
    1.43 +The Mail Submission Agent (MSA) is called
    1.44 +\fIMessage Transfer Service\fP (MTS) in nmh.
    1.45  The facility established network connections and spoke SMTP to submit
    1.46  messages for relay to the outside world.
    1.47  This part was implemented by the
    1.48 @@ -95,22 +95,24 @@
    1.49  The requirement to parse the recipient addresses out of the message header 
    1.50  is likely to be removed in the future.
    1.51  Then mmh would give the recipient addresses as command line arguments.
    1.52 -This is clearly the better interface, but mmh does not provide it yet.
    1.53 +This appears to be the better interface.
    1.54  .\" XXX implement it
    1.55  .P
    1.56  To retrieve mail, the
    1.57  .Pn inc
    1.58 -command established network connections
    1.59 +command acted as Mail Retrieval Agent (MRA).
    1.60 +It established network connections
    1.61  and spoke POP3 to retrieve mail from remote servers.
    1.62  As with mail submission, the network connections required encryption and
    1.63  authentication, thus TLS and SASL were added.
    1.64  Support for message retrieval through IMAP will become necessary
    1.65 -to be added soon, too, and so on for any changes in mail transfer.
    1.66 -Mmh has dropped the support for retrieving mail from remote locations.
    1.67 +to be added soon, too, and likewise for any other changes in mail transfer.
    1.68 +Not so for mmh because it has dropped the support for retrieving mail
    1.69 +from remote locations.
    1.70  .Ci ab7b48411962d26439f92f35ed084d3d6275459c
    1.71  Instead, it depends on an external tool to cover this task.
    1.72 -In mmh there exist two paths for messages to enter mmh's mail storage:
    1.73 -(1) Mail can be incorporate with
    1.74 +In mmh exist two paths for messages to enter mmh's mail storage:
    1.75 +(1) Mail can be incorporated with
    1.76  .Pn inc
    1.77  from the system maildrop, or (2) with
    1.78  .Pn rcvstore
    1.79 @@ -118,9 +120,6 @@
    1.80  .P
    1.81  With the removal of the MSA and MRA, mmh converted from an all-in-one
    1.82  mail system to being a MUA only.
    1.83 -Following the Unix philosophy, it now focuses on one job and
    1.84 -tries to do that one well.
    1.85 -Not only the programs follow that tenet but also the project itself does so.
    1.86  Now, of course, mmh depends on third-party software.
    1.87  An external MSA is required to transfer mail to the outside world;
    1.88  an external MRA is required to retrieve mail from remote machines.
    1.89 @@ -137,7 +136,7 @@
    1.90  or
    1.91  .Pn less
    1.92  aren't available, appears to be ridiculous.
    1.93 -Now, an MSA or MRA is more complex than a text pager
    1.94 +Of course, MSAs and MRAs are more complex than text pagers
    1.95  and not necessarily available but still the concept of orthogonal
    1.96  design holds: ``Write programs that do one thing and do it well.''
    1.97  .[
    1.98 @@ -153,7 +152,7 @@
    1.99  ``Develop projects that focus on one thing and do it well.''
   1.100  Projects grown complex should be split for the same reasons programs grown
   1.101  complex should be split.
   1.102 -If it is conceptionally more elegant to have the MSA and MRA
   1.103 +If it is conceptionally more elegant to have the MSA and MRA as
   1.104  separate projects then they should be separated.
   1.105  This is the case here, in my opinion.
   1.106  The RFCs propose this separation by clearly distinguishing the different
   1.107 @@ -164,31 +163,31 @@
   1.108  The small interfaces between the mail agents support the separation.
   1.109  .P
   1.110  In the beginning, email had been small and simple.
   1.111 -(\c
   1.112 +At that time,
   1.113  .Pn /bin/mail
   1.114 -had once covered anything there was to email and still had been small
   1.115 -and simple.)
   1.116 -Then the essential complexity of email increased.
   1.117 +had covered anything there was to email and still had been small
   1.118 +and simple.
   1.119 +Later, the essential complexity of email increased.
   1.120  (Essential complexity is the complexity defined by the problem itself.\0
   1.121  .[[
   1.122  brooks no silver bullet
   1.123  .]])
   1.124  Email systems reacted to this change: They grew.
   1.125 -RFCs started to introduce mail agents and separated the various tasks
   1.126 -because the existing tasks became more extensive and new tasks appeared.
   1.127 -Again, email systems grew, or they split parts off.
   1.128 -In nmh, for instance, the POP server, which the original MH had included,
   1.129 -was removed.
   1.130 -Now is the time to go one step further and remove the MSA and MRA, too.
   1.131 +RFCs started to introduce the concept of mail agents to separate the
   1.132 +various tasks because they became more extensive and new tasks appeared.
   1.133 +As the mail systems grew even more, parts were split off.
   1.134 +In nmh, for instance, the POP server, which was included in the original
   1.135 +MH, was removed.
   1.136 +Now is the time to go one step further and split the MSA and MRA off, too.
   1.137  Not only does this decrease the code size of the project,
   1.138  but, more important, it unburdens mmh of the whole field of
   1.139  message transfer with all its implications for the project.
   1.140 -There's no more need to concern with changes in network transfer.
   1.141 +There is no more need to concern with changes in network transfer.
   1.142  This independence is received by depending on an external program
   1.143  that covers the field.
   1.144  Today, this is a reasonable exchange.
   1.145  .P
   1.146 -Function can be added in three different ways:
   1.147 +Functionality can be added in three different ways:
   1.148  .BU
   1.149  Implementing the function originally in the project.
   1.150  .BU
   1.151 @@ -207,7 +206,7 @@
   1.152  thus information can be exchanged more flexible.
   1.153  Adding code to a project increases maintenance work.
   1.154  .\" XXX ref
   1.155 -Implementing complex functions originally in the project will add
   1.156 +Implementing complex functions originally in the project adds
   1.157  a lot of code.
   1.158  This should be avoided if possible.
   1.159  Hence, the dependencies only change in kind, not in their existence.
   1.160 @@ -249,14 +248,14 @@
   1.161  .I fdm .
   1.162  
   1.163  
   1.164 -.H2 "Removal of non-MUA Tools
   1.165 +.H2 "Non-MUA Tools
   1.166  .P
   1.167  One goal of mmh is to remove the tools that are not part of the MUA's task.
   1.168  Further more, any tools that don't improve the MUA's job significantly
   1.169  should be removed.
   1.170  Loosely related and rarely used tools distract from the lean appearance.
   1.171  They require maintenance work without adding much to the core task.
   1.172 -On removing these tools, the project shall become more stream-lined
   1.173 +By removing these tools, the project shall become more stream-lined
   1.174  and focused.
   1.175  In mmh the following tools are not available anymore:
   1.176  .BU
   1.177 @@ -282,7 +281,7 @@
   1.178  If users like to be informed of new mail, the shell's
   1.179  .Ev MAILPATH
   1.180  variable or graphical notifications are technically more appealing.
   1.181 -Writing directly to a terminals is hardly ever wanted today.
   1.182 +Writing directly to terminals is hardly ever wanted today.
   1.183  If though one wants to have it this way, the standard tool
   1.184  .Pn write
   1.185  can be used in a way similar to:
   1.186 @@ -312,11 +311,11 @@
   1.187  .VS
   1.188  ls -l /var/mail/meillo
   1.189  VE
   1.190 -It did distinguished between old and new mail, but
   1.191 -this detail information and can be retrieved with
   1.192 +It did distinguish between old and new mail, but
   1.193 +this detail information can be retrieved with
   1.194  .Pn stat (1),
   1.195  too.
   1.196 -A very small shell script could be written to output the information
   1.197 +A small shell script could be written to print the information
   1.198  in a similar way, if truly necessary.
   1.199  As mmh's
   1.200  .Pn inc
   1.201 @@ -344,8 +343,7 @@
   1.202  .Pn wmh ,
   1.203  saved more than 7\|000 lines of C code \(en
   1.204  about 15\|% of the project's original source code amount.
   1.205 -.P
   1.206 -Having less code (with equal readability, of course)
   1.207 +Having less code \(en with equal readability, of course \(en
   1.208  for the same functionality is an advantage.
   1.209  Less code means less bugs and less maintenance work.
   1.210  As
   1.211 @@ -369,9 +367,10 @@
   1.212  .Pn slocal .
   1.213  .Pn slocal
   1.214  is an MDA and thus not directly MUA-related.
   1.215 -It should be removed, because including it is a violation
   1.216 -of the idea that mmh is a MUA only.
   1.217 -It should become a separate project.
   1.218 +It should be removed from mmh, because including it conflicts with
   1.219 +the idea that mmh is a MUA only.
   1.220 +.Pn slocal
   1.221 +should rather become a separate project.
   1.222  However,
   1.223  .Pn slocal
   1.224  provides rule-based processing of messages, like filing them into
   1.225 @@ -379,8 +378,8 @@
   1.226  Although
   1.227  .Pn slocal
   1.228  does neither pull in dependencies nor does it include a separate
   1.229 -technical area (cf. Sec. XXX),
   1.230 -still it accounts for about 1\|000 lines of code that need to be maintained.
   1.231 +technical area (cf. Sec. XXX), still,
   1.232 +it accounts for about 1\|000 lines of code that need to be maintained.
   1.233  As
   1.234  .Pn slocal
   1.235  is almost self-standing, it should be split off into a separate project.
   1.236 @@ -390,24 +389,25 @@
   1.237  .Pn slocal
   1.238  would become yet another independent MDA, like
   1.239  .I procmail .
   1.240 -The need to install a complete MH system to have
   1.241 +Then
   1.242  .Pn slocal
   1.243 -would be gone.
   1.244 +could be installed without the complete MH system.
   1.245  Likewise, mmh users could decide to use
   1.246  .I procmail
   1.247  without having a second, unused MDA,
   1.248  .Pn slocal ,
   1.249  installed.
   1.250 -That's conceptionally the best solution.
   1.251 +That appears to be conceptionally the best solution.
   1.252  Yet,
   1.253  .Pn slocal
   1.254  is not split off.
   1.255 -I feel unsure with removing it from mmh.
   1.256 -Hence, I defer the decision over
   1.257 -.Pn slocal .
   1.258 -In the meanwhile
   1.259 +I defer the decision over
   1.260  .Pn slocal
   1.261 -does not hurt because it is unrelated to the rest of mmh.
   1.262 +in need for deeper investigation.
   1.263 +In the meanwhile, it remains part of mmh.
   1.264 +That does not hurt because
   1.265 +.Pn slocal
   1.266 +is unrelated to the rest of the project.
   1.267  
   1.268  
   1.269  .H2 "\fLshow\fP and \fPmhshow\fP
   1.270 @@ -420,8 +420,8 @@
   1.271  .Pn mhl
   1.272  to have the files formatted.
   1.273  With MIME, this approach wasn't sufficient anymore.
   1.274 -MIME messages can consist of multiple parts, some of which aren't
   1.275 -directly displayable, further more text content might be encoded in
   1.276 +MIME messages can consist of multiple parts. Some parts are not
   1.277 +directly displayable and text content might be encoded in
   1.278  foreign charsets.
   1.279  .Pn show 's
   1.280  understanding of messages and
   1.281 @@ -487,7 +487,7 @@
   1.282  Different behavior would have surprised the user.
   1.283  .P
   1.284  Today, non-MIME messages are rather seen to be a special case of
   1.285 -MIME messages, although it's the other way round.
   1.286 +MIME messages, although it is the other way round.
   1.287  As
   1.288  .Pn mhshow
   1.289  had already be able to display non-MIME messages, it appeared natural
   1.290 @@ -549,7 +549,7 @@
   1.291  supporting MIME demands for higher essential complexity.
   1.292  
   1.293  
   1.294 -.H2 "Removal of Configure Options
   1.295 +.H2 "Configure Options
   1.296  .P
   1.297  Customization is a double-edged sword.
   1.298  It allows better suiting setups, but not for free.
   1.299 @@ -560,7 +560,7 @@
   1.300  The code complexity directly affects the developers.
   1.301  Less tested code affects both, users and developers.
   1.302  The problem of choice affects the users, for once by having to
   1.303 -choose, but also by complexer interfaces that require more documentation.
   1.304 +choose, but also by more complex interfaces that require more documentation.
   1.305  Whenever options add little advantages, they should be considered for
   1.306  removal.
   1.307  I have reduced the number of project-specific configure options from 
   1.308 @@ -598,13 +598,16 @@
   1.309  More variations require more testing and maintenance work.
   1.310  .P
   1.311  Two other options only specified default configuration values:
   1.312 -.Sw --with-mts=[smtp|sendmail]
   1.313 -defined the default transport service.
   1.314 +.Sw --with-mts
   1.315 +defined the default transport service, either
   1.316 +.Ar smtp
   1.317 +or
   1.318 +.Ar sendmail .
   1.319  In mmh this fixed to
   1.320  .Ar sendmail .
   1.321  .Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
   1.322  With
   1.323 -.Sw --with-smtpservers=[server1...]
   1.324 +.Sw --with-smtpservers
   1.325  default SMTP servers for the
   1.326  .Ar smtp
   1.327  transport service could be specified.
   1.328 @@ -624,11 +627,12 @@
   1.329  option was named
   1.330  .Sw --with-backup-prefix.
   1.331  and had the prefix symbol as argument.
   1.332 -Because giving the hash symbol as argument caused to many problems
   1.333 -for configure,
   1.334 -the option was limited to use the hash symbol as the default prefix.
   1.335 -This makes me believe, that the choice for the hash was personal preference.
   1.336 -Being it related or not, words that start with the hash symbol
   1.337 +But giving the hash symbol as argument caused too many problems
   1.338 +for Autoconf,
   1.339 +thus the option was limited to use the hash symbol as the default prefix.
   1.340 +This supports the assumption, that the choice for the hash was
   1.341 +personal preference only.
   1.342 +Being related or not, words that start with the hash symbol
   1.343  introduce a comment in the Unix shell.
   1.344  Thus, the command line
   1.345  .Cl "rm #13 #15
   1.346 @@ -639,7 +643,7 @@
   1.347  To delete the backup files,
   1.348  .Cl "rm ./#13 ./#15"
   1.349  needs to be used.
   1.350 -Using the hash as backup prefix can be seen as a precaution agains
   1.351 +Using the hash as backup prefix can be seen as a precaution against
   1.352  data loss.
   1.353  .P
   1.354  I removed the configure option but added the profile entry
   1.355 @@ -654,8 +658,8 @@
   1.356  .Cf "Sec. XXX
   1.357  obsoleted the concept of the backup prefix completely.
   1.358  .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
   1.359 -(Well, there still are corner-cases to remove until the backup
   1.360 -prefix can be laid to rest, eventually.)
   1.361 +.\" (Well, there still are corner-cases to remove until the backup
   1.362 +.\" prefix can be laid to rest, eventually.)
   1.363  .\" FIXME: Do this work in the code!
   1.364  
   1.365  .U3 "Editor and Pager
   1.366 @@ -748,13 +752,6 @@
   1.367  the new behavior confirms better to the common style on Unix systems.
   1.368  Additionally, the new approach is more uniform and clearer to users.
   1.369  
   1.370 -.U3 "Locale
   1.371 -.P
   1.372 -The configure option
   1.373 -.Sw --disable-locale
   1.374 -was removed because POSIX provides locale support and there's
   1.375 -hardly any need to disable locale support.
   1.376 -.Ci ccf4f175ef4c4e7522f9510a4a1149c15d810dd9
   1.377  
   1.378  .U3 "ndbm
   1.379  .P
   1.380 @@ -771,7 +768,7 @@
   1.381  .Sw -suppressdup
   1.382  switch.)
   1.383  .P
   1.384 -A variety of version of the database library exist.
   1.385 +A variety of versions of the database library exist.
   1.386  .[
   1.387  wolter unix incompat notes dbm
   1.388  .]
   1.389 @@ -937,7 +934,7 @@
   1.390  
   1.391  
   1.392  
   1.393 -.H2 "Removal of Switches
   1.394 +.H2 "Command Line Switches
   1.395  .P
   1.396  The command line switches of MH tools follow the X Window style.
   1.397  They are words, introduced by a single dash.
   1.398 @@ -1021,12 +1018,14 @@
   1.399  .\" XXX Ref
   1.400  displays the number of switches for each of the tools that is available
   1.401  in both, nmh and mmh.
   1.402 -Visible as well as hidden switches were counted,
   1.403 +The tools are sorted by the number of switches they had in nmh.
   1.404 +Visible and hidden switches were counted,
   1.405  but not the generic help and version switches.
   1.406  Whereas in the beginning of the project, the average tool had 11 switches,
   1.407  now it has no more than 5 \(en only half as many.
   1.408  If the `no' switches and similar inverse variant are folded onto
   1.409 -their counter-parts, the average tool has 8 switches in pre-mmh to 4 now.
   1.410 +their counter-parts, the average tool had 8 switches in pre-mmh times and
   1.411 +has 4 now.
   1.412  The total number of functional switches in mmh dropped from 465
   1.413  to 234.
   1.414  
   1.415 @@ -1050,15 +1049,14 @@
   1.416  
   1.417  .U3 "Draft Folder Facility
   1.418  .P
   1.419 -A change early in the project was the completely transition from
   1.420 +A change early in the project was the complete transition from
   1.421  the single draft message to the draft folder facility.
   1.422  .Ci 337338b404931f06f0db2119c9e145e8ca5a9860
   1.423 -The draft folder facility was introduced in the mid-Eighties.
   1.424 -(Rose and Romine called it a ``relatively new feature''
   1.425 +The draft folder facility was introduced in the mid-Eighties, when
   1.426 +Rose and Romine called it a ``relatively new feature''.
   1.427  .[
   1.428  rose romine real work
   1.429  .]
   1.430 -in 1985.)
   1.431  Since then, the facility had existed but was deactivated by default.
   1.432  The default activation and the related rework of the tools made it
   1.433  possible to remove the
   1.434 @@ -1103,7 +1101,7 @@
   1.435  .Pn anno
   1.436  had the switches
   1.437  .Sw -[no]inplace
   1.438 -to either annotate the message inplace and thus preserve hard links,
   1.439 +to either annotate the message in place and thus preserve hard links,
   1.440  or annotate a copy to replace the original message, breaking hard links.
   1.441  Following the assumption that linked messages should truly be the
   1.442  same message, and annotating it should not break the link, the
   1.443 @@ -1227,7 +1225,8 @@
   1.444  .U3 "MIME Tools
   1.445  .P
   1.446  The MIME tools, which were once part of
   1.447 -.Pn mhn ,
   1.448 +.Pn mhn
   1.449 +[sic!],
   1.450  had several switches that added little practical value to the programs.
   1.451  The
   1.452  .Sw -[no]realsize
   1.453 @@ -1449,7 +1448,7 @@
   1.454  .P
   1.455  The
   1.456  .Sw -noedit
   1.457 -switches of
   1.458 +switch of
   1.459  .Pn comp ,
   1.460  .Pn repl ,
   1.461  .Pn forw ,
   1.462 @@ -1484,17 +1483,15 @@
   1.463  .P
   1.464  Effectively, the
   1.465  .Sw -nowhatnowproc
   1.466 -switch stored a copy of the form file into the draft folder.
   1.467 +switch creates only a draft message.
   1.468  As
   1.469  .Cl "-whatnowproc true
   1.470  causes the same behavior, the
   1.471  .Sw -nowhatnowproc
   1.472  switch was removed for being redundant.
   1.473 -Likely, however, the intention for specifying
   1.474 +Likely, the
   1.475  .Sw -nowhatnowproc
   1.476 -is sending a fully prepared form file at once.
   1.477 -This can be done with
   1.478 -.Cl "-whatnowproc send" .
   1.479 +switch was intended to be used by front-ends.
   1.480  
   1.481  
   1.482  .U3 "Compatibility Switches
   1.483 @@ -1651,7 +1648,7 @@
   1.484  .H1 "Modernizing
   1.485  
   1.486  
   1.487 -.H2 "Removal of Code Relicts
   1.488 +.H2 "Code Relicts
   1.489  .P
   1.490  The code base of mmh originates from the late Seventies,
   1.491  had been extensively
   1.492 @@ -1901,7 +1898,7 @@
   1.493  
   1.494  
   1.495  
   1.496 -.H1 "Code style
   1.497 +.H1 "Code Style
   1.498  .P
   1.499  foo
   1.500