1.1 --- a/ch01.roff	Thu May 17 19:26:59 2012 +0200
     1.2 +++ b/ch01.roff	Fri May 18 11:21:51 2012 +0200
     1.3 @@ -3,27 +3,25 @@
     1.4  .H0 "Introduction
     1.5  .P
     1.6  This chapter introduces MH, its history, concepts and how it is used.
     1.7 -Then, it describes nmh's code base and community to give the reader
     1.8 +It describes nmh's code base and community to give the reader
     1.9  a better understanding of the state from which mmh started off.
    1.10 -Further more, this chapter lists the motivation and goals of the mmh project.
    1.11 -This chapter introduces MH, nmh and mmh to the reader and outlines
    1.12 -the mmh project itself.
    1.13 +Further more, this chapter outlines the mmh project itself,
    1.14 +describing the motivation for it and its goals.
    1.15  
    1.16  
    1.17  .H1 "MH \(en the Mail Handler
    1.18  .P
    1.19 -MH is an electronic mail system, originating in the RAND Corporation.
    1.20 -Most important for this thesis is that MH defines a mail handling concept.
    1.21 -In fact, MH had started as a design proposal, not as an implementation,
    1.22 -and in spirit it had remained this way. This is similar to Unix, which
    1.23 +MH is a conceptual email system design and its concrete implementation.
    1.24 +Notably, MH had started as a design proposal at RAND Corporation,
    1.25 +where the first implementation followed later.
    1.26 +In spirit, MH is similar to Unix, which
    1.27  influenced the world more in being a set of system design concepts
    1.28  than in being a specific software product.
    1.29 -These ideas behind Unix are summarized in the \fIUnix philosophy\fP.
    1.30 +The ideas behind Unix are summarized in the \fIUnix philosophy\fP.
    1.31  MH follows this philosophy.
    1.32  
    1.33  .U2 "History
    1.34  .P
    1.35 -MH is an electronic mail system, originating in the RAND Corporation.
    1.36  In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
    1.37  had proposed the design
    1.38  of a new mail handling system, called ``Mail Handler'' (MH),
    1.39 @@ -31,48 +29,55 @@
    1.40  Two years later, in 1979, Bruce Borden took the proposal and implemented a
    1.41  prototype of MH.
    1.42  Before the prototype had been available, the concept was
    1.43 -believed to be practically unusable because of being too slow.
    1.44 -But the prototype proved successful and replaced MS thereafter.
    1.45 -In replacing MS, MH became an all-in-one mail system.
    1.46 +believed to be practically unusable.
    1.47 +But the prototype had proven successful and replaced MS thereafter.
    1.48 +In replacing MS, MH grew to an all-in-one mail system.
    1.49  .P
    1.50 -A decade later, the University of California at Irvine had started to use MH.
    1.51 +In the early Eighties,
    1.52 +the University of California at Irvine (UCI) had started to use MH.
    1.53  They also took over its development and pushed MH forward.
    1.54 -This was the time when the Internet appeared, UCB implemented
    1.55 -the TCP/IP stack, and Allman wrote Sendmail.
    1.56 -MH was extended as emailing got more features.
    1.57 +Marshall T. Rose and John L. Romine became the driving force then.
    1.58 +This was the time when the Internet appeared, when UCB implemented
    1.59 +the TCP/IP stack, and when Allman wrote Sendmail.
    1.60 +MH was extended as emailing became more featured.
    1.61  The development of MH was closely related to the development of email
    1.62  RFCs. In the advent of MIME, MH was the first implementation of this new
    1.63  email standard.
    1.64  .P
    1.65 -In the nineties, MH had been moved into the public domain, making it
    1.66 +In the Nineties, MH had been moved into the public domain, making it
    1.67  attractive to Free Software developers.
    1.68 -The Internet had started to become popular and in 1997,
    1.69 -Richard Coleman initiated the ``New Mail Handler'' (nmh) project,
    1.70 -a fork of MH, based on the \fILBL changes\fP by Van Jacobson, Mike Karels
    1.71 -and Craig Leres.
    1.72 +The Internet had became popular and in December 1996,
    1.73 +Richard Coleman initiated the ``New Mail Handler'' (nmh) project.
    1.74 +The project is a fork of MH 6.8.3 and bases strongly on the
    1.75 +\fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres.
    1.76  Colman intended to modernize MH and improve its portability and
    1.77  MIME handling capabilities.
    1.78  This should be done openly within the Internet community.
    1.79 -The development of MH stopped soon after the development of nmh had started.
    1.80 +The development of MH at UCI stopped after the 6.8.4 release in
    1.81 +February 1996, soon after the development of nmh had started.
    1.82  Today, nmh almost completely replaced the original MH.
    1.83 +Some systems might still provide old MH, but mainly for historical reasons.
    1.84 +.P
    1.85 +In the last years, the work on nmh was mostly maintenance work.
    1.86 +However, the development revived in December 2011 and stayed busy since then.
    1.87  
    1.88  .U2 "Concepts
    1.89  .P
    1.90  MH is a toolchest, modelled after the Unix toolchest. It consists of a
    1.91 -set of tools, each covering a specific task of email handling.
    1.92 -The programs
    1.93 -operate on a common mail storage. The specific format of the mail storage
    1.94 -characterizes MH in the same way like the format of the file system
    1.95 -characterizes Unix.
    1.96 +set of tools, each covering a specific task of email handling, like
    1.97 +composing a message, replying to a message, refiling a message to a
    1.98 +different folder, listing the messages in a folder.
    1.99 +All of the programs operate on a common mail storage.
   1.100  .P
   1.101  The mail storage consists of \fImail folders\fP (directories) and
   1.102  \fPmessages\fP (regular files).
   1.103  Each message is stored in a separate file in the format it had been
   1.104 -received (i.e. transfer format). The files are named with ascending numbers
   1.105 -in each folder.
   1.106 +received (i.e. transfer format).
   1.107 +The files are named with ascending numbers in each folder.
   1.108 +The specific format of the mail storage characterizes MH in the same way
   1.109 +like the format of the file system characterizes Unix.
   1.110  .P
   1.111 -MH tools maintain a \fIcontext\fP, which includes
   1.112 -the current mail folder and current message.
   1.113 +MH tools maintain a \fIcontext\fP, which includes the current mail folder.
   1.114  Processes in Unix have a similar context, containing the current working
   1.115  directory, for instance. In contrast, the process context is maintained
   1.116  by the Unix kernel automatically, whereas MH tools need to maintain the MH
   1.117 @@ -80,50 +85,28 @@
   1.118  The user can have one MH context or multiple ones, he can even share it
   1.119  with other users.
   1.120  .P
   1.121 -Messages can have symbolic names. These can be automatically updated
   1.122 +Messages are named by their numeric filename, but they can have symbolic names,
   1.123 +too. These are either automatically updated
   1.124  position names like being the next or the last message,
   1.125  or user-settable group names for arbitrary sets of messages.
   1.126  These names are called sequences.
   1.127 -Sequences can be bound to the folder or to the context.
   1.128 +Sequences can be bound to the containing folder or to the context.
   1.129  .P
   1.130 -New MH tools are built out of or on top of existing ones easily \(en
   1.131 -a property common to toolchests.
   1.132 -Multiple versions of the same command with different default values
   1.133 -are created very easily. This provides shortcuts and tayloring.
   1.134 -Form templates for new messages or for replies are easily exchangable.
   1.135 -Generally, output is adjustable with format files.
   1.136 +The user's \fIprofile\fP is a file that contains his MH configuration.
   1.137 +Default switches for the individual tools can be specified to
   1.138 +adjust them to the user's personal preferences.
   1.139 +Multiple versions of the same command with different
   1.140 +default values can also be created very easily.
   1.141 +Form templates for new messages or for replies are easily changable,
   1.142 +and output is adjustable with format files.
   1.143 +Almost every part of the system can be adjusted to personal preference.
   1.144  .P
   1.145 -The configuration is stored in a file that is called the user's \fIprofile\fP.
   1.146 -MH encourages the user to taylor and automate the mail handling.
   1.147 -Almost every part of the system can be adjusted to personal preference.
   1.148  The system is well scriptable and extendable.
   1.149 +New MH tools are built out of or on top of existing ones quickly.
   1.150 +Further more, MH encourages the user to taylor, extend and automate the system.
   1.151  As the MH toolchest was modelled after the Unix toolchest, the
   1.152  properties of the latter apply to the former as well.
   1.153  
   1.154 -.U2 "Versions
   1.155 -.P
   1.156 -Three versions of MH are available today:
   1.157 -.IP "Old MH"
   1.158 -.br
   1.159 -In most cases this version had been replaced by nmh,
   1.160 -but some systems might still provide old MH.
   1.161 -The main reasons to still use old MH are historical reasons.
   1.162 -MH provides hardly any benefits over nmh.
   1.163 -The development of old MH has stopped after the 6.8.4 release in
   1.164 -February 1996.
   1.165 -.IP nmh
   1.166 -.br
   1.167 -The most widespread version of MH was forked off version 6.8.3 in December
   1.168 -1996. It is based on the \fILBL changes\fP.
   1.169 -Backward-compatibility to old MH is provided by having new featues deactivated
   1.170 -by default. In consequence, the user needs to activate them explicitely to
   1.171 -be able to use them.
   1.172 -Throughout the previous years, the work on nmh was mostly maintenance work.
   1.173 -Development revived in December 2011 and stayed busy since then.
   1.174 -.IP mmh
   1.175 -.br
   1.176 -This descendent of nmh is the subject of this thesis.
   1.177 -It had started as an experimental version, but became de facto a fork.
   1.178  
   1.179  .U2 "Example Session
   1.180  .P
   1.181 @@ -208,12 +191,15 @@
   1.182  user-visible access to whole messages and MIME parts are inherently
   1.183  different).
   1.184  .P
   1.185 -For compatibility's sake, it is a common understanding to have the
   1.186 +For backward-compatibility's sake, it is a common understanding to have the
   1.187  default settings to be compatible, requiring any new feature to be
   1.188 -explicitely enabled. This puts a burden on new users, because nmh
   1.189 +explicitely enabled.
   1.190 +In consequence, the user needs to activate modern features explicitely
   1.191 +to be able to use them.
   1.192 +This puts a burden on new users, because nmh
   1.193  out-of-the-box keeps staying in the same ancient style, where users
   1.194  usually want to have it practical for modern emailing.
   1.195 -But of course, this depends on if nmh is seen to be a front-end or a
   1.196 +But of course, this depends if nmh is seen to be a front-end or a
   1.197  back-end.
   1.198  
   1.199  
   1.200 @@ -250,7 +236,7 @@
   1.201  grown large and lost it's leanness.
   1.202  This should not happen to mmh.
   1.203  .P
   1.204 -mmh can also stand for \fImodern mail handler\fP, and this is
   1.205 +Mmh can also stand for \fImodern mail handler\fP, and this is
   1.206  the variant chosen as titel for this document. One main focus of the
   1.207  project was to modernize nmh. Another main goal is resembled in the
   1.208  name \fIminimized mail handler\fP: Drop any parts that don't add

     2.1 --- a/preface.roff	Thu May 17 19:26:59 2012 +0200
     2.2 +++ b/preface.roff	Fri May 18 11:21:51 2012 +0200
     2.3 @@ -1,14 +1,11 @@
     2.4  .H0 "Preface" no
     2.5  
     2.6  .P
     2.7 -MH is a set of mail handling tools with a common concept, like
     2.8 -the Unix toolchest is a set of file handling tools with a common
     2.9 +MH is a set of mail handling tools with a common concept, similar to
    2.10 +the Unix toolchest, which is a set of file handling tools with a common
    2.11  concept. nmh is the currently most popular implementation of an
    2.12  MH-like mail handling system.
    2.13 -This thesis describes an experimental version of nmh,
    2.14 -named \fImmh\fP.
    2.15 -The project goals for mmh are modernizing, stream-lining and exploiting
    2.16 -MH's concepts even more thoroughly.
    2.17 +This thesis describes an experimental version of nmh, named \fImmh\fP.
    2.18  
    2.19  .U2 "Background to this Thesis
    2.20  .P
    2.21 @@ -102,8 +99,8 @@
    2.22  
    2.23  .U2 "Focus of this Document
    2.24  .P
    2.25 -This document describes my work on the experimental nmh version, named
    2.26 -\fImmh\fP. It explains the changes to nmh, with focus on their reasons.
    2.27 +This document describes my work on mmh.
    2.28 +It explains the changes to nmh, with focus on their reasons.
    2.29  It discusses technical, historical, social and philosophical considerations.
    2.30  On the technical side, this document
    2.31  explains how an existing project was stream-lined by removing rough edges
    2.32 @@ -170,7 +167,7 @@
    2.33  .[
    2.34  gancarz unix phil
    2.35  .]
    2.36 -Even better but less concrete are ``The UNIX Programming Environment''
    2.37 +Even better, though less concrete, are ``The UNIX Programming Environment''
    2.38  .[
    2.39  kernighan pike unix prog env
    2.40  .]