1.1 --- a/discussion.roff	Mon Jul 09 22:32:24 2012 +0200
     1.2 +++ b/discussion.roff	Mon Jul 09 23:42:59 2012 +0200
     1.3 @@ -29,6 +29,7 @@
     1.4  Procmail is a specialized MDA, and Fetchmail is a specialized MRA.
     1.5  I believe that it is best to use such specialized tools instead of
     1.6  providing the same function again as a side-component in the project.
     1.7 +.\" XXX mail agent picture here
     1.8  .P
     1.9  Doing something well, requires to focus on a small set of specific aspects.
    1.10  Under the assumption that focused development produces better results
    1.11 @@ -165,9 +166,9 @@
    1.12  Here, this part of the Unix philosophy was applied not only
    1.13  to the programs but to the project itself.
    1.14  In other words:
    1.15 -``Develop projects that focus on one thing and do it well.''
    1.16 -Projects grown complex should be split for the same reasons programs grown
    1.17 -complex should be split.
    1.18 +Develop projects that focus on one thing and do it well.
    1.19 +Projects grown complex should be split for the same reasons programs
    1.20 +grown complex should be split.
    1.21  If it is conceptionally more elegant to have the MSA and MRA as
    1.22  separate projects then they should be separated.
    1.23  This is the case here, in my opinion.
    1.24 @@ -194,7 +195,7 @@
    1.25  As the mail systems grew even more, parts were split off.
    1.26  In nmh, for instance, the POP server, which was included in the original
    1.27  MH, was removed.
    1.28 -Now is the time to go one step further and split the MSA and MRA off, too.
    1.29 +Now is the time to go one step further and split off the MSA and MRA, too.
    1.30  Not only does this decrease the code size of the project,
    1.31  but, more important, it unburdens mmh of the whole field of
    1.32  message transfer with all its implications for the project.
    1.33 @@ -557,6 +558,7 @@
    1.34  first.
    1.35  (cf. Sec.
    1.36  .Cf mhshow )
    1.37 +.\" XXX code commits?
    1.38  Once the tools behaved more alike, the replacing appeared to be
    1.39  even more natural.
    1.40  Today, mmh's new
    1.41 @@ -647,21 +649,18 @@
    1.42  .P
    1.43  Two other options only specified default configuration values:
    1.44  .Sw --with-mts
    1.45 -defined the default transport service, either
    1.46 -.Ar smtp
    1.47 -or
    1.48 -.Ar sendmail .
    1.49 -.\" XXX naechster Satz ganz raus?
    1.50 -In mmh this fixed to
    1.51 -.Ar sendmail .
    1.52 +defined the default transport service.
    1.53  .Ci f6aa95b724fd8c791164abe7ee5468bf5c34f226
    1.54  With
    1.55  .Sw --with-smtpservers
    1.56 -default SMTP servers for the
    1.57 -.Ar smtp
    1.58 -transport service could be specified.
    1.59 +default SMTP servers could be specified.
    1.60  .Ci 128545e06224233b7e91fc4c83f8830252fe16c9
    1.61 -Both of them became irrelevant.
    1.62 +Both of them became irrelevant when the SMTP transport service was removed.
    1.63 +.\" XXX code ref
    1.64 +In mmh, all messages are handed over to
    1.65 +.Pn sendmail
    1.66 +for transportation.
    1.67 +
    1.68  
    1.69  .U3 "Backup Prefix
    1.70  .P
    1.71 @@ -707,7 +706,7 @@
    1.72  Eventually, however, the new trash folder concept
    1.73  (cf. Sec.
    1.74  .Cf trash-folder )
    1.75 -obsoleted the concept of the backup prefix completely.
    1.76 +removed the need for the backup prefix completely.
    1.77  .Ci 8edc5aaf86f9f77124664f6801bc6c6cdf258173
    1.78  .Ci ca0b3e830b86700d9e5e31b1784de2bdcaf58fc5
    1.79  
    1.80 @@ -997,7 +996,7 @@
    1.81  .Sw -help ,
    1.82  to print a short message on how to use the program, and 
    1.83  .Sw -Version
    1.84 -[sic!], to tell what version of mmh the program belongs to.
    1.85 +(with capital `V'), to tell what version of mmh the program belongs to.
    1.86  .P
    1.87  Switches change the behavior of programs.
    1.88  Programs that do one thing in one way require no switches.
    1.89 @@ -1103,6 +1102,7 @@
    1.90  A change early in the project was the complete transition from
    1.91  the single draft message to the draft folder facility.
    1.92  .Ci 337338b404931f06f0db2119c9e145e8ca5a9860
    1.93 +.\" XXX ref to section ...
    1.94  The draft folder facility was introduced in the mid-eighties, when
    1.95  Rose and Romine called it a ``relatively new feature''.
    1.96  .[
    1.97 @@ -1138,14 +1138,13 @@
    1.98  the rework of the draft system.
    1.99  (cf. Sec.
   1.100  .Cf draft-folder )
   1.101 -Equally,
   1.102 +Furthermore,
   1.103  .Pn comp
   1.104 -lost its
   1.105 +no longer needs a
   1.106  .Sw -file
   1.107 -switch.
   1.108 -The draft folder facility, together with the
   1.109 +switch as the draft folder facility together with the
   1.110  .Sw -form
   1.111 -switch, are sufficient.
   1.112 +switch are sufficient.
   1.113  
   1.114  
   1.115  .U3 "In Place Editing
   1.116 @@ -1189,9 +1188,10 @@
   1.117  Nmh's
   1.118  .Mp burst (1)
   1.119  man page reads:
   1.120 -.sp \n(PDu
   1.121  .QS
   1.122 -If -noinplace is given, each digest is preserved, no table
   1.123 +If
   1.124 +.Sw -noinplace
   1.125 +is given, each digest is preserved, no table
   1.126  of contents is produced, and the messages contained within
   1.127  the digest are placed at the end of the folder. Other messages
   1.128  are not tampered with in any way.
   1.129 @@ -1278,7 +1278,8 @@
   1.130  .P
   1.131  The MIME tools, which were once part of
   1.132  .Pn mhn
   1.133 -[sic!],
   1.134 +.\" XXX
   1.135 +(whatever that stood for),
   1.136  had several switches that added little practical value to the programs.
   1.137  The
   1.138  .Sw -[no]realsize
   1.139 @@ -1410,14 +1411,26 @@
   1.140  man page for
   1.141  .Mp comp (1):
   1.142  .QS
   1.143 -The \-editor editor switch indicates the editor to use for
   1.144 -the initial edit. Upon exiting from the editor, comp will
   1.145 -invoke the whatnow program. See whatnow(1) for a discussion
   1.146 -of available options. The invocation of this program can be
   1.147 -inhibited by using the \-nowhatnowproc switch. (In truth of
   1.148 -fact, it is the whatnow program which starts the initial
   1.149 -edit. Hence, \-nowhatnowproc will prevent any edit from
   1.150 -occurring.)
   1.151 +The
   1.152 +.Sw -editor
   1.153 +.Ar editor
   1.154 +switch indicates the editor to use for
   1.155 +the initial edit. Upon exiting from the editor,
   1.156 +.Pn comp
   1.157 +will invoke the
   1.158 +.Pn whatnow
   1.159 +program. See
   1.160 +.Mp whatnow (1)
   1.161 +for a discussion of available options.
   1.162 +The invocation of this program can be
   1.163 +inhibited by using the
   1.164 +.Sw -nowhatnowproc
   1.165 +switch. (In truth of fact, it is the
   1.166 +.Pn whatnow
   1.167 +program which starts the initial edit.
   1.168 +Hence,
   1.169 +.Sw -nowhatnowproc
   1.170 +will prevent any edit from occurring.)
   1.171  .QE
   1.172  .P
   1.173  Effectively, the
   1.174 @@ -1510,10 +1523,14 @@
   1.175  Normally when a message is refiled, for each destination
   1.176  folder it is assigned the number which is one above the current
   1.177  highest message number in that folder. Use of the
   1.178 -\-preserv [sic!] switch will override this message renaming, and try
   1.179 +.Sw -preserv
   1.180 +[sic!] switch will override this message renaming, and try
   1.181  to preserve the number of the message. If a conflict for a
   1.182 -particular folder occurs when using the \-preserve switch,
   1.183 -then refile will use the next available message number which
   1.184 +particular folder occurs when using the
   1.185 +.Sw -preserve
   1.186 +switch, then
   1.187 +.Pn refile
   1.188 +will use the next available message number which
   1.189  is above the message number you wish to preserve.
   1.190  .QE
   1.191  
   1.192 @@ -1585,7 +1602,7 @@
   1.193  .\" --------------------------------------------------------------
   1.194  .H1 "Modernizing
   1.195  .P
   1.196 -In the more thirty years of MH's existence, its code base was
   1.197 +In the more than thirty years of MH's existence, its code base was
   1.198  increasingly extended.
   1.199  New features entered the project and became alternatives to the
   1.200  existing behavior.
   1.201 @@ -1618,9 +1635,9 @@
   1.202  discuss whether to keep using vfork, just note in [sic!] passing, [...]
   1.203  we don't need a separate branch for removing vmh
   1.204  or ridding ourselves of #ifdef's or removing posix replacement functions
   1.205 -or depending on pure ansi/posix "libc".
   1.206 +or depending on pure ansi/posix ``libc''.
   1.207  .QP
   1.208 -these things should each be a day or two of work and the "main branch"
   1.209 +these things should each be a day or two of work and the ``main branch''
   1.210  should just be modern. [...]
   1.211  let's push forward, aggressively.
   1.212  .QE
   1.213 @@ -2556,10 +2573,9 @@
   1.214  .P
   1.215  Similar to the situation for drafts is the situation for removed messages.
   1.216  Historically, a message was ``deleted'' by prepending a specific
   1.217 -\fIbackup prefix\fP, usually the comma character,
   1.218 -to the file name.
   1.219 -The specific message would vanish from MH because only files with
   1.220 -non-digit characters in their name are not treated as messages.
   1.221 +\fIbackup prefix\fP, usually the comma character, to the file name.
   1.222 +The specific file would then be ignored by MH because only files with
   1.223 +names consisting of digits only are treated as messages.
   1.224  Although files remained in the file system,
   1.225  the messages were no more visible in MH.
   1.226  To truly delete them, a maintenance job is needed.
   1.227 @@ -2570,15 +2586,15 @@
   1.228  VE
   1.229  In such a setup, the original message can be restored
   1.230  within the grace time interval by stripping the
   1.231 -the backup prefix from the file name.
   1.232 -But one can not rely on this statement.
   1.233 +backup prefix from the file name.
   1.234 +But the user can not rely on this statement.
   1.235  If the last message of a folder with six messages (1-6) is removed,
   1.236  message
   1.237  .Fn 6 ,
   1.238  becomes file
   1.239  .Fn ,6 .
   1.240  If then a new message enters the same folder, it will be given
   1.241 -the number one higher than the highest existing message.
   1.242 +the number one higher than the highest message.
   1.243  In this case the message is named
   1.244  .Fn 6
   1.245  then.
   1.246 @@ -2594,12 +2610,12 @@
   1.247  same folder is removed before.'' the statement becomes complex.
   1.248  A user will hardly be able to keep track of any removal to know
   1.249  if the assertion still holds true for a specific file.
   1.250 -The the real mechanism is practically obscure to the user.
   1.251 +In practice, the real mechanism is unclear to the user.
   1.252  The consequences of further removals are not obvious.
   1.253  .P
   1.254  Further more, the backup files are scattered within the whole mail storage.
   1.255  This complicates managing them.
   1.256 -It is possible, with help of
   1.257 +It is possible with the help of
   1.258  .Pn find ,
   1.259  but everything would be more convenient
   1.260  if the deleted messages would be collected in one place.
   1.261 @@ -2609,7 +2625,7 @@
   1.262  (previously named
   1.263  .Pe Delete-Prog )
   1.264  was introduced very early to improve the situation.
   1.265 -It could be set to any command, which would be executed to removed
   1.266 +It could be set to any command, which would be executed to remove
   1.267  the specified messages.
   1.268  This would override the default action, described above.
   1.269  Refiling the to-be-removed files to a garbage folder is the usual example.
   1.270 @@ -2631,7 +2647,7 @@
   1.271  because they are all collected in one place.
   1.272  Existing and removed messages are thus separated more strictly.
   1.273  No backup files are silently overwritten.
   1.274 -Most important is the ability to keep removed messages in the MH domain.
   1.275 +But most important is the ability to keep removed messages in the MH domain.
   1.276  Messages in the trash folder can be listed like those in any other folder.
   1.277  Deleted messages can be displayed like any other messages.
   1.278  Restoring a deleted messages can be done with
   1.279 @@ -2648,7 +2664,7 @@
   1.280  to move the to-be-removed message to the trash folder,
   1.281  .Fn +trash
   1.282  by default.
   1.283 -To sweep it clean, one can use
   1.284 +To sweep it clean, the user can use
   1.285  .Cl "rmm -unlink +trash a" ,
   1.286  where the
   1.287  .Sw -unlink
   1.288 @@ -2667,9 +2683,9 @@
   1.289  .Pn refile ,
   1.290  which used to be the other way round.
   1.291  Yet, the relationship is simpler now.
   1.292 -No more can loops, like described in nmh's man page for
   1.293 +Loops, like described in nmh's man page for
   1.294  .Mp refile (1),
   1.295 -occur:
   1.296 +can no longer occur:
   1.297  .QS
   1.298  Since
   1.299  .Pn refile
   1.300 @@ -3040,10 +3056,13 @@
   1.301  .Sw -list
   1.302  read:
   1.303  .QS
   1.304 -The -list option produces a listing of the field bodies for
   1.305 +The
   1.306 +.Sw -list
   1.307 +option produces a listing of the field bodies for
   1.308  header fields with names matching the specified component,
   1.309 -one per line. The listing is numbered, starting at 1, if
   1.310 -the -number option is also used.
   1.311 +one per line. The listing is numbered, starting at 1, if the
   1.312 +.Sw -number
   1.313 +option is also used.
   1.314  .QE
   1.315  .LP
   1.316  The problem was manifold.
   1.317 @@ -3342,21 +3361,36 @@
   1.318  I asked John Romine and here's what he had to say, which
   1.319  agrees and provides an example that convinces me:
   1.320  .QS
   1.321 -My take on this is that post should not be called by
   1.322 -users directly, and it doesn't read the .mh_profile
   1.323 +My take on this is that
   1.324 +.Pn post
   1.325 +should not be called by users directly, and it doesn't read the
   1.326 +.Fn .mh_profile
   1.327  (only front-end UI programs read the profile).
   1.328  .QP
   1.329 -For example, there can be contexts where post is called
   1.330 -by a helper program (like 'mhmail') which may be run by
   1.331 -a non-MH user.  We don't want this to prompt the user
   1.332 -to create an MH profile, etc.
   1.333 +For example, there can be contexts where
   1.334 +.Pn post
   1.335 +is called by a helper program (like `\c
   1.336 +.Pn mhmail ')
   1.337 +which may be run by a non-MH user.
   1.338 +We don't want this to prompt the user to create an MH profile, etc.
   1.339  .QP
   1.340 -My suggestion would be to have send pass a (hidden)
   1.341 -`\-fileproc proc' option to post if needed.  You could also
   1.342 -use an environment variable (I think send/whatnow do
   1.343 -this).
   1.344 +My suggestion would be to have
   1.345 +.Pn send
   1.346 +pass a (hidden) `\c
   1.347 +.Sw -fileproc
   1.348 +.Ar proc '
   1.349 +option to
   1.350 +.Pn post
   1.351 +if needed.
   1.352 +You could also
   1.353 +use an environment variable (I think
   1.354 +.Pn send /\c
   1.355 +.Pn whatnow
   1.356 +do this).
   1.357  .QE
   1.358 -I think that's the way to go.  My personal preference is to use a command line option, not an environment variable.
   1.359 +I think that's the way to go.
   1.360 +My personal preference is to use a command line option,
   1.361 +not an environment variable.
   1.362  .QE
   1.363  .P
   1.364  To solve the problem of

     2.1 --- a/intro.roff	Mon Jul 09 22:32:24 2012 +0200
     2.2 +++ b/intro.roff	Mon Jul 09 23:42:59 2012 +0200
     2.3 @@ -38,7 +38,7 @@
     2.4  Before the prototype's existence, the concept was
     2.5  believed to be practically unusable.
     2.6  But the prototype proved successful and replaced MS thereafter.
     2.7 -In replacing MS, MH grew to an all-in-one mail system.
     2.8 +In replacing MS, MH grew to provide anything necessary for emailing.
     2.9  .P
    2.10  In the early eighties,
    2.11  the University of California at Irvine (UCI) started to use MH.
    2.12 @@ -83,7 +83,8 @@
    2.13  The specific format of the mail storage characterizes MH in the same way
    2.14  as the format of the file system characterizes Unix.
    2.15  .P
    2.16 -MH tools maintain a \fIcontext\fP, which includes the current mail folder.
    2.17 +MH tools maintain a \fIcontext\fP, which includes for instance the
    2.18 +current mail folder.
    2.19  Processes in Unix have a similar context, containing the current working
    2.20  directory, for instance. In contrast, the process context is maintained
    2.21  by the Unix kernel automatically, whereas MH tools need to maintain the MH
    2.22 @@ -91,8 +92,9 @@
    2.23  The user can have one MH context or multiple ones; he can even share it
    2.24  with others.
    2.25  .P
    2.26 -Messages are named by their numeric filename, but they can have symbolic names,
    2.27 -too. These are either automatically updated
    2.28 +Messages are named by their numeric filename,
    2.29 +but they can have symbolic names, too.
    2.30 +These are either automatically updated
    2.31  position names such as the next or the last message,
    2.32  or user-settable group names for arbitrary sets of messages.
    2.33  These names are called sequences.
    2.34 @@ -101,8 +103,8 @@
    2.35  The user's \fIprofile\fP is a file that contains his MH configuration.
    2.36  Default switches for the individual tools can be specified to
    2.37  adjust them to the user's personal preferences.
    2.38 -Multiple versions of the same command with different
    2.39 -default values can also be created very easily.
    2.40 +Additionally, a single command can be linked under different names
    2.41 +with different default values easily.
    2.42  Form templates for new messages or for replies are easily changeable,
    2.43  and output is adjustable with format files.
    2.44  Almost every part of the system can be adjusted to personal preference.
    2.45 @@ -177,7 +179,8 @@
    2.46  Then it grew, spread and adapted to the changes email went through.
    2.47  Its core-concepts, however, remained the same.
    2.48  During the eighties, students at UCI actively worked on MH.
    2.49 -They added new features and optimized the code for the then popular systems.
    2.50 +They added new features and optimized the code for the systems
    2.51 +popular at that time.
    2.52  All this still was in times before POSIX and ANSI C.
    2.53  As large parts of the code stem from this time, today's nmh source code
    2.54  still contains many ancient parts.
    2.55 @@ -231,6 +234,7 @@
    2.56  
    2.57  .H1 "mmh
    2.58  .P
    2.59 +.\" XXX which version did I ``fork''?
    2.60  I started to work on my experimental version in October 2011,
    2.61  at a time when there had been no more than three commits to nmh
    2.62  since the beginning of the year.
    2.63 @@ -247,6 +251,7 @@
    2.64  After long years of stagnation, nmh became actively developed again.
    2.65  Hence, while I was working on mmh, the community was once more working
    2.66  on nmh, in parallel.
    2.67 +.\" XXX interaction between nmh and mmh
    2.68  .P
    2.69  The name \fImmh\fP may stand for \fImodern mail handler\fP,
    2.70  because the project tries to modernize nmh.
    2.71 @@ -314,7 +319,7 @@
    2.72  .P
    2.73  The mmh project provides the basis on which the aforementioned
    2.74  ideas can be implemented and demonstrated,
    2.75 -without the need to change nmh or its community.
    2.76 +without the need to change the nmh project or its community.
    2.77  Of course, the results of the mmh project shall improve nmh, in the end.
    2.78  By no means it is my intent to work against the nmh project.
    2.79  
    2.80 @@ -339,8 +344,8 @@
    2.81  non-ASCII text, and digital cryptography.
    2.82  They are able to setup email system components besides mmh,
    2.83  and actually like to have the choice to pick the ones they prefer.
    2.84 -They have a reasonably modern operating system that complies to standards,
    2.85 -like POSIX and ANSI C.
    2.86 +They have a reasonably modern operating system that complies to the
    2.87 +POSIX and ANSI C standards.
    2.88  .P
    2.89  The typical users invoke mmh commands directly in an interactive
    2.90  shell session, but they use them to automate mail handling tasks as well.
    2.91 @@ -385,7 +390,8 @@
    2.92  All tools should be tightly shaped.
    2.93  .IP "Modernizing
    2.94  Mmh's feature set needs to become more modern.
    2.95 -Better support for attachment and digital cryptography should be added.
    2.96 +Better support for attachments, digital signatures and message encryption
    2.97 +should be added.
    2.98  MIME support should be integrated deeper and more naturally.
    2.99  The modern email features need to be readily available, out-of-the-box.
   2.100  On the other hand,

     3.1 --- a/preface.roff	Mon Jul 09 22:32:24 2012 +0200
     3.2 +++ b/preface.roff	Mon Jul 09 23:42:59 2012 +0200
     3.3 @@ -13,7 +13,7 @@
     3.4  and editing already, it was not too difficult.
     3.5  In contrast, setting up nmh to a convenient state became a tedious task
     3.6  that took several months.
     3.7 -Once having nmh arranged to a convenient state, I enjoyed using it
     3.8 +Once having nmh arranged this way, I enjoyed using it
     3.9  because of its conceptional elegance and its scripting capabilities.
    3.10  Nevertheless, it was still inconvenient for handling attachments,
    3.11  non-ASCII character encodings, and similar features of modern emailing.
    3.12 @@ -131,14 +131,15 @@
    3.13  .[
    3.14  kernighan ritchie c prog lang
    3.15  .]
    3.16 -A book about system-level C programming can be helpful
    3.17 -additional literature, such as those written by Rochkind and Curry.
    3.18 +A book about system-level C programming, such as those written by
    3.19 +Rochkind and Curry,
    3.20  .[
    3.21  rochkind advanced unix prog
    3.22  .]
    3.23  .[
    3.24  curry system prog
    3.25  .]
    3.26 +can be helpful as additional literature.
    3.27  Old books are likely more helpful for understanding,
    3.28  because large parts of the source code are old.
    3.29  The reader is expected to know the format of email messages and
    3.30 @@ -194,12 +195,11 @@
    3.31  Chapter 2 discusses the work done in the project.
    3.32  It is organized along the three major goals of the project, namely
    3.33  streamlining, modernizing, and styling.
    3.34 -Not all the work done in the project is described,
    3.35 -because that would bore the reader.
    3.36 +Not every change is described because that would bore the reader.
    3.37  Instead, important changes and those standing for a set of similar
    3.38  changes are described and discussed.
    3.39  Chapter 3 finishes up by summarizing the achivements and taking
    3.40 -an outlook to the future of the mmh project.
    3.41 +a look into the future of the mmh project.
    3.42  .P
    3.43  .I "Italic font
    3.44  is used to emphasize new terms.

     4.1 --- a/summary.roff	Mon Jul 09 22:32:24 2012 +0200
     4.2 +++ b/summary.roff	Mon Jul 09 23:42:59 2012 +0200
     4.3 @@ -24,10 +24,10 @@
     4.4  developing and using, without lacking important functionality.
     4.5  
     4.6  
     4.7 -.U2 "Work Left to Do
     4.8 +.U2 "Outlook
     4.9  .P
    4.10  The work done during the project is not finished.
    4.11 -Several tasks are left to do, mainly the MIME integration.
    4.12 +Several tasks are left to do.
    4.13  .P
    4.14  MIME handling is the most complex part of mmh and it requires
    4.15  general rework.
    4.16 @@ -54,7 +54,7 @@
    4.17  .Hd Subject
    4.18  remain unsolved.
    4.19  .P
    4.20 -Besides MIME-related tasks, some tools were not worked on yet.
    4.21 +Some of mmh's tools were hardly touched during my work.
    4.22  Among them are
    4.23  .Pn dist ,
    4.24  .Pn rcvdist ,
    4.25 @@ -62,19 +62,30 @@
    4.26  .Pn pick ,
    4.27  and
    4.28  .Pn sortm .
    4.29 -Concerning
    4.30 +Related to
    4.31  .Pn sortm ,
    4.32  a threaded message view is completely missing to mmh, yet.
    4.33  .Pn pick
    4.34 -could profit from message indexing.
    4.35 -No research was performed in this field.
    4.36 +could be enhanced by message indexing.
    4.37 +These fields are worthwhile for research.
    4.38  .P
    4.39  The features most often asked for are Maildir and IMAP support.
    4.40  Yet, both of them collide with MH in the same fundamental way as
    4.41  different filesystem approaches would collide with Unix.
    4.42 -Nevertheless, a storage back-end abstraction layer could provide
    4.43 -a mapping from such back-ends to the MH storage format.
    4.44 +Nevertheless, an abstraction layer could provide a mapping from such
    4.45 +storage back-ends to the MH storage format.
    4.46 +Or the mmh toolchest could be reworked to operate on a generic back-end,
    4.47 +making the MH storage format only one of many possible back-ends.
    4.48  Research in this area is highly appreciated.
    4.49 +.\" XXX targeting the right problems?!
    4.50 +.P
    4.51 +Nmh has a testing framework that supported the developers by detecting
    4.52 +several subtle bugs.
    4.53 +All refactoring in mmh had been done without the safety net of a test
    4.54 +framework.
    4.55 +Hence, experience warns that the probability for subtle bugs lurking
    4.56 +in the code base is high.
    4.57 +Nmh's test framework should be adjusted to mmh and extended.
    4.58  
    4.59  
    4.60  .U2 "Relationship to nmh
    4.61 @@ -85,6 +96,7 @@
    4.62  discussions for each step I liked to take,
    4.63  I started to create an experimental version to convicce by demonstration
    4.64  of the result.
    4.65 +.\" behind closed doors; talks I've given
    4.66  My worked on mmh was independent of the nmh community.
    4.67  This enabled me to follow my vision straightly and thus produce
    4.68  a result of greater pureness.