--- a/ch03.roff	Sun May 20 22:10:22 2012 +0200
+++ b/ch03.roff	Fri Jun 01 12:33:49 2012 +0200
@@ -1,10 +1,159 @@
-.H0 "Work Report
+.H0 "Discussion
+.P
+This main chapter discusses the practical work done in the mmh project.
+It is structured along the goals to achieve. The concrete work done
+is described in the examples of how the general goals were achieved.
+
+
+
+
+.H1 "Stream-lining
+
+
+.H2 "Removal of non-MUA Tools
+.P
+MH had been considered an all-in-one system for mail handling.
+The community around nmh has a similar understanding.
+In fundamental difference, I believe that mmh should be a MUA but
+nothing more. I believe that all-in-one mail systems are not the way
+to go. There are excellent specialized MTAs, like Postfix;
+there are specialized MDAs, like Procmail; there are specialized
+MRAs, like Fetchmail. I believe it's best to use them instead of
+providing the same function ourselves. Doing something well requires to
+focus on this particular aspect or a small set of aspects. The more
+it is possible to focus, the better the result in this particular
+area will be. The limiting resource in Free Software community development
+usually is human power. If the low development power is even parted
+into multiple development areas, it will hardly be possible to 
+compete with the specialists in the various fields. This is even
+increased, given the small community \(en developers and users \(en
+that MH-based mail systems have. In consequence, I believe that the
+available resources should be concentrated at the point where MH is
+most unique. This is clearly the MUA part.
 .P
-foo
+Several of nmh's tools were removed from mmh because they didn't
+match the main focus of adding to the MUA's task.
+.P
+.Pn conflict
+was removed because it is a mail system maintenance tool.
+Besides, it also checks the
+.Fn /etc/passwd
+and
+.Fn /etc/group
+files.
+The tool might be useful, but it should not be shipped with mmh.
+.P
+.Pn rcvtty
+was removed because its usecase of writing to the user's terminal
+on receiving of mail is hardly wanted today. If users like to be
+informed of new mail, then using the shell's
+.Ev MAILPATH
+variable or different (graphical) notifications are likely more
+appealing. Writing directly to other terminals is hardly ever wanted
+today. If though one wants to have it this way, the standard tool
+.Pn write
+can be used in a way similar to:
+.DS
+scan -file - | write `id -un`
+.DE
+.P
+When the new attachment system was introduced,
+.Pn viamail
+was removed because then
+.Pn forw
+could cover the task itself.
+The wrapper program
+.Pn sendfiles
+was rewritten as a shell script to use
+.Pn forw .
 .P
-bar
+.Pn msgchk
+was removed as it became hardly useful when POP support was removed.
+It is questionable if
+.Pn msgchk
+provides more information than:
+.DS
+ls -l /var/mail/meillo
+.DE
+It does separate between old and new mail, but that's not very
+useful and can be found out with
+.Pn stat (1)
+too. A very small shell script could care for the form of output.
+As mmh's inc only incorporates mail from the user's local maildrop
+and thus no long data transfers are involved,
+there's no need to check for new mail before incorporating it.
+.P
+.Pn msh
+was removed because the tool was in conflict with the original
+philosophy of MH. It provided an interactive shell to access the
+features of MH. One major feature of MH is being a tool chest.
+.Pn msh
+wouldn't be just another shell, tailored to the needs of mail
+handling, but one large program to have the MH tools built in.
+It's main use was for accessing Bulletin Boards, which have seized to
+be popular. Removing
+.Pn msh ,
+together with the truly obsolete programs
+.Pn vmh
+and
+.Pn wmh ,
+saved more than 7\|000 lines of C code \(en a major achievement.
+
+.U2 "Removal of the MTS
+.P
+
 
-.H1 "Removal of Code Relicts
+.H2 "mhshow show Merge
+.P
+Since the very beginning, already in the first concept paper,
+.Pn show
+had been MH's mail display program.
+.Pn show
+found out which pathnames the relevant messages had and invoked
+.Pn mhl
+then to let it render the content.
+With the advent of MIME, this approach wasn't sufficient anymore.
+MIME messages can consist of multiple parts, some of which aren't
+directly displayable, and text content can be encoded in
+foreign charsets.
+.Pn show 's
+simple approach and
+.Pn mhl 's
+limited display facilities couldn't cope with the task any longer.
+Instead of extending these tools, new ones were written from scratch
+and then added to the MH tool chest. Doing so is encouraged by the
+tool chest approach. The new tools could be added without interfering
+with the existing ones. This is great. It allowed MH to be the
+first MUA to implement MIME.
+.P
+The new MIME features were added in form of the single program
+.Pn mhn .
+The command
+.DS
+mhn \-show 42
+.DE
+would show the MIME message numbered 42.
+With the 1.0 release of nmh in February 1999, Richard Coleman finished
+the split of
+.Pn mhn
+into a set of specialized programs, which together covered the
+aspects of MIME. One of these resulting tools was
+.Pn mhshow .
+
+
+.H2 "Removal of Configure Options
+.P
+
+.H2 "Removal of switches
+.P
+
+
+
+
+.H1 "Moderizing
+
+
+.H2 "Removal of Code Relicts
 .P
 The code base of mmh originates from the late Seventies,
 had been extensively
@@ -215,263 +364,36 @@
 common today.
 
 
-.H1 "Removal of Tools
+.H2 "Attachments
 .P
-MH had been considered an all-in-one system for mail handling.
-The community around nmh has a similar understanding.
-In fundamental difference, I believe that mmh should be a MUA but
-nothing more. I believe that all-in-one mail systems are not the way
-to go. There are excellent specialized MTAs, like Postfix;
-there are specialized MDAs, like Procmail; there are specialized
-MRAs, like Fetchmail. I believe it's best to use them instead of
-providing the same function ourselves. Doing something well requires to
-focus on this particular aspect or a small set of aspects. The more
-it is possible to focus, the better the result in this particular
-area will be. The limiting resource in Free Software community development
-usually is human power. If the low development power is even parted
-into multiple development areas, it will hardly be possible to 
-compete with the specialists in the various fields. This is even
-increased, given the small community \(en developers and users \(en
-that MH-based mail systems have. In consequence, I believe that the
-available resources should be concentrated at the point where MH is
-most unique. This is clearly the MUA part.
-.P
-Several of nmh's tools were removed from mmh because they didn't
-match the main focus of adding to the MUA's task.
-.P
-.Pn conflict
-was removed because it is a mail system maintenance tool.
-Besides, it also checks the
-.Fn /etc/passwd
-and
-.Fn /etc/group
-files.
-The tool might be useful, but it should not be shipped with mmh.
+MIME
+
+
+.H2 "Digital Cryptography
 .P
-.Pn rcvtty
-was removed because its usecase of writing to the user's terminal
-on receiving of mail is hardly wanted today. If users like to be
-informed of new mail, then using the shell's
-.Ev MAILPATH
-variable or different (graphical) notifications are likely more
-appealing. Writing directly to other terminals is hardly ever wanted
-today. If though one wants to have it this way, the standard tool
-.Pn write
-can be used in a way similar to:
-.DS
-scan -file - | write `id -un`
-.DE
-.P
-When the new attachment system was introduced,
-.Pn viamail
-was removed because then
-.Pn forw
-could cover the task itself.
-The wrapper program
-.Pn sendfiles
-was rewritten as a shell script to use
-.Pn forw .
+Signing and encryption.
+
+
+.H2 "Good Defaults
 .P
-.Pn msgchk
-was removed as it became hardly useful when POP support was removed.
-It is questionable if
-.Pn msgchk
-provides more information than:
-.DS
-ls -l /var/mail/meillo
-.DE
-It does separate between old and new mail, but that's not very
-useful and can be found out with
-.Pn stat (1)
-too. A very small shell script could care for the form of output.
-As mmh's inc only incorporates mail from the user's local maildrop
-and thus no long data transfers are involved,
-there's no need to check for new mail before incorporating it.
-.P
-.Pn msh
-was removed because the tool was in conflict with the original
-philosophy of MH. It provided an interactive shell to access the
-features of MH. One major feature of MH is being a tool chest.
-.Pn msh
-wouldn't be just another shell, tailored to the needs of mail
-handling, but one large program to have the MH tools built in.
-It's main use was for accessing Bulletin Boards, which have seized to
-be popular. Removing
-.Pn msh ,
-together with the truly obsolete programs
-.Pn vmh
-and
-.Pn wmh ,
-saved more than 7\|000 lines of C code \(en a major achievement.
+foo
 
 
-.H1 "Draft and Trash Folders
-.U2 "Draft Folder
-.P
-Historically, MH provided exactly one draft message, named
-.Fn draft
-and
-being located in the MH directory. When starting to compose another message
-before the former one was sent, the user had been questioned whether to use,
-refile or replace the old draft. Working on multiple drafts at the same time
-was impossible. One could only work on them in alteration by refiling the
-previous one to some directory and fetching some other one for reediting. 
-This manual draft management needed to be done each time the user wanted
-to switch between editing one draft to editing another.
-.P
-To allow true parallel editing of drafts, in a straight forward way, the
-draft folder facility exists. It had been introduced already in July 1984
-by Marshall T. Rose. The facility was deactivated by default.
-Even in nmh, the draft folder facility remained deactivated by default.
-At least, Richard Coleman added the man page
-.Mp mh-draft(5)
-to document
-the feature well.
-.P
-The only advantage of not using the draft folder facility is the static
-name of the draft file. This could be an issue for MH frontends like mh-e.
-But as they likely want to provide working on multiple drafts in parallel,
-the issue is only concerning compatibility. The aim of nmh to stay compatible
-prevented the default activation of the draft folder facility.
-.P
-On the other hand, a draft folder is the much more natural concept than
-a draft message. MH's mail storage consists of folders and messages,
-the messages named with ascending numbers. A draft message breaks with this
-concept by introducing a message in a file named
-.Fn draft .
-This draft
-message is special. It can not be simply listed with the available tools,
-but instead requires special switches. I.e. corner-cases were
-introduced. A draft folder, in contrast, does not introduce such
-corner-cases. The available tools can operate on the messages within that
-folder like on any messages within any mail folders. The only difference
-is the fact that the default folder for
-.Pn send
-is the draft folder,
-instead of the current folder, like for all other tools.
-.P
-The trivial part of the change was activating the draft folder facility
-by default and setting a default name for this folder. Obviously, I chose
-the name
-.Fn +drafts .
-This made the
-.Sw \-draftfolder
-and
-.Sw \-draftmessage
-switches useless, and I could remove them.
-The more difficult but also the part that showed the real improvement,
-was updating the tools to the new concept.
-.Sw \-draft
-switches could
-be dropped, as operating on a draft message became indistinguishable to
-operating on any other message for the tools.
-.Pn comp
-still has its
-.Sw \-use
-switch for switching between its two modes: (1) Compose a new
-draft, possibly by taking some existing message as a form. (2) Modify
-an existing draft. In either case, the behavior of
-.Pn comp is
-deterministic. There is no more need to query the user. I consider this
-a major improvement. By making
-.Pn send
-simply operate on the current
-message in the draft folder by default, with message and folder both
-overridable by specifying them on the command line, it is now possible
-to send a draft anywhere within the storage by simply specifying its folder
-and name.
-.P
-All theses changes converted special cases to regular cases, thus
-simplifying the tools and increasing the flexibility.
+
 
-.U2 "Trash Folder
+.H1 "Code style
 .P
-Similar to the situation for drafts is the situation for removed messages.
-Historically, a message was deleted by renaming. A specific
-\fIbackup prefix\fP, often comma (\c
-.Fn , )
-or hash (\c
-.Fn # ),
-being prepended to the file name. Thus, MH wouldn't recognize the file
-as a message anymore, as only files whose name consists of digits only
-are treated as messages. The removed messages remained as files in the
-same directory and needed some maintenance job to truly delete them after
-some grace time. Usually, by running a command similar to
-.DS
-find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
-.DE
-in a cron job. Within the grace time interval
-the original message could be restored by stripping the
-the backup prefix from the file name. If however, the last message of
-a folder is been removed \(en say message
-.Fn 6
-becomes file
-.Fn ,6
-\(en and a new message enters the same folder, thus the same
-numbered being given again \(en in our case
-.Fn 6
-\(en, if that one
-is removed too, then the backup of the former message gets overwritten.
-Thus, the ability to restore removed messages does not only depend on
-the ``sweeping cron job'' but also on the removing of further messages.
-This is undesirable, because the real mechanism is hidden from the user
-and the consequences of further removals are not always obvious.
-Further more, the backup files are scattered within the whole mail
-storage, instead of being collected at one place.
-.P
-To improve the situation, the profile entry
-.Pe rmmproc
-(previously named
-.Pe Delete-Prog )
-was introduced, very early.
-It could be set to any command, which would care for the mail removal
-instead of taking the default action, described above.
-Refiling the to-be-removed files to some garbage folder was a common
-example. Nmh's man page
-.Mp rmm(1)
-proposes
-.Cl "refile +d
-to move messages to the garbage folder and
-.Cl "rm `mhpath +d all`
-the empty the garbage folder.
-Managing the message removal this way is a sane approach. It keeps
-the removed messages in one place, makes it easy to remove the backup
-files, and, most important, enables the user to use the tools of MH
-itself to operate on the removed messages. One can
-.Pn scan
-them,
-.Pn show
-them, and restore them with
-.Pn refile .
-There's no more
-need to use
-.Pn mhpath
-to switch over from MH tools to Unix tools \(en MH can do it all itself.
-.P
-This approach matches perfect with the concepts of MH, thus making
-it powerful. Hence, I made it the default. And even more, I also
-removed the old backup prefix approach, as it is clearly less powerful.
-Keeping unused alternative in the code is a bad choice as they likely
-gather bugs, by not being constantly tested. Also, the increased code
-size and more conditions crease the maintenance costs. By strictly
-converting to the trash folder approach, I simplified the code base.
-.Pn rmm
-calls
-.Pn refile
-internally to move the to-be-removed
-message to the trash folder (\c
-.Fn +trash
-by default). Messages
-there can be operated on like on any other message in the storage.
-The sweep clean, one can use
-.Cl "rmm \-unlink +trash a" ,
-where the
-.Sw \-unlink
-switch causes the files to be truly unliked instead
-of moved to the trash folder.
+foo
 
 
-.H1 "MH Directory Split
+.H2 "Standard Code
+.P
+POSIX
+
+
+.H2 "Separation
+
+.U2 "MH Directory Split
 .P
 In MH and nmh, a personal setup had consisted of two parts:
 The MH profile, named
@@ -563,77 +485,203 @@
 split between mail storage and personal configuration files.
 
 
-.H1 "Path Notations
-.P
-foo
-
-.H1 "Attachments
-.P
-foo
-
-.H1 "mhshow to show Transition
-.P
-Since the very beginning, already in the first concept paper,
-.Pn show
-had been MH's mail display program.
-.Pn show
-found out which pathnames the relevant messages had and invoked
-.Pn mhl
-then to let it render the content.
-With the advent of MIME, this approach wasn't sufficient anymore.
-MIME messages can consist of multiple parts, some of which aren't
-directly displayable, and text content can be encoded in
-foreign charsets.
-.Pn show 's
-simple approach and
-.Pn mhl 's
-limited display facilities couldn't cope with the task any longer.
-Instead of extending these tools, new ones were written from scratch
-and then added to the MH tool chest. Doing so is encouraged by the
-tool chest approach. The new tools could be added without interfering
-with the existing ones. This is great. It allowed MH to be the
-first MUA to implement MIME.
+.H2 "Modularization
 .P
-The new MIME features were added in form of the single program
-.Pn mhn .
-The command
-.DS
-mhn \-show 42
-.DE
-would show the MIME message numbered 42.
-With the 1.0 release of nmh in February 1999, Richard Coleman finished
-the split of
-.Pn mhn
-into a set of specialized programs, which together covered the
-aspects of MIME. One of these resulting tools was
-.Pn mhshow .
-
-
-.H1 "Blind Carbon Copies
+whatnowproc
 .P
-foo
-
-.H1 "Good Defaults
-.P
-foo
-
-.H1 "Modularization
-.P
-foo
-
-.H1 "Code style
-.P
-foo
-
-
-
-(e.g. the
-user-visible access to whole messages and MIME parts are inherently
-different).
-
 The \fIMH library\fP
 .Fn libmh.a
 collects a bunch of standard functions that many of the MH tools need,
 like reading the profile or context files.
 This doesn't hurt the separation.
 
+
+.H2 "Style
+.P
+Code layout, goto, ...
+
+
+
+
+.H1 "Concept Exploitation/Homogeniety
+
+
+.H2 "Draft Folder
+.P
+Historically, MH provided exactly one draft message, named
+.Fn draft
+and
+being located in the MH directory. When starting to compose another message
+before the former one was sent, the user had been questioned whether to use,
+refile or replace the old draft. Working on multiple drafts at the same time
+was impossible. One could only work on them in alteration by refiling the
+previous one to some directory and fetching some other one for reediting. 
+This manual draft management needed to be done each time the user wanted
+to switch between editing one draft to editing another.
+.P
+To allow true parallel editing of drafts, in a straight forward way, the
+draft folder facility exists. It had been introduced already in July 1984
+by Marshall T. Rose. The facility was deactivated by default.
+Even in nmh, the draft folder facility remained deactivated by default.
+At least, Richard Coleman added the man page
+.Mp mh-draft(5)
+to document
+the feature well.
+.P
+The only advantage of not using the draft folder facility is the static
+name of the draft file. This could be an issue for MH frontends like mh-e.
+But as they likely want to provide working on multiple drafts in parallel,
+the issue is only concerning compatibility. The aim of nmh to stay compatible
+prevented the default activation of the draft folder facility.
+.P
+On the other hand, a draft folder is the much more natural concept than
+a draft message. MH's mail storage consists of folders and messages,
+the messages named with ascending numbers. A draft message breaks with this
+concept by introducing a message in a file named
+.Fn draft .
+This draft
+message is special. It can not be simply listed with the available tools,
+but instead requires special switches. I.e. corner-cases were
+introduced. A draft folder, in contrast, does not introduce such
+corner-cases. The available tools can operate on the messages within that
+folder like on any messages within any mail folders. The only difference
+is the fact that the default folder for
+.Pn send
+is the draft folder,
+instead of the current folder, like for all other tools.
+.P
+The trivial part of the change was activating the draft folder facility
+by default and setting a default name for this folder. Obviously, I chose
+the name
+.Fn +drafts .
+This made the
+.Sw \-draftfolder
+and
+.Sw \-draftmessage
+switches useless, and I could remove them.
+The more difficult but also the part that showed the real improvement,
+was updating the tools to the new concept.
+.Sw \-draft
+switches could
+be dropped, as operating on a draft message became indistinguishable to
+operating on any other message for the tools.
+.Pn comp
+still has its
+.Sw \-use
+switch for switching between its two modes: (1) Compose a new
+draft, possibly by taking some existing message as a form. (2) Modify
+an existing draft. In either case, the behavior of
+.Pn comp is
+deterministic. There is no more need to query the user. I consider this
+a major improvement. By making
+.Pn send
+simply operate on the current
+message in the draft folder by default, with message and folder both
+overridable by specifying them on the command line, it is now possible
+to send a draft anywhere within the storage by simply specifying its folder
+and name.
+.P
+All theses changes converted special cases to regular cases, thus
+simplifying the tools and increasing the flexibility.
+
+
+.H2 "Trash Folder
+.P
+Similar to the situation for drafts is the situation for removed messages.
+Historically, a message was deleted by renaming. A specific
+\fIbackup prefix\fP, often comma (\c
+.Fn , )
+or hash (\c
+.Fn # ),
+being prepended to the file name. Thus, MH wouldn't recognize the file
+as a message anymore, as only files whose name consists of digits only
+are treated as messages. The removed messages remained as files in the
+same directory and needed some maintenance job to truly delete them after
+some grace time. Usually, by running a command similar to
+.DS
+find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
+.DE
+in a cron job. Within the grace time interval
+the original message could be restored by stripping the
+the backup prefix from the file name. If however, the last message of
+a folder is been removed \(en say message
+.Fn 6
+becomes file
+.Fn ,6
+\(en and a new message enters the same folder, thus the same
+numbered being given again \(en in our case
+.Fn 6
+\(en, if that one
+is removed too, then the backup of the former message gets overwritten.
+Thus, the ability to restore removed messages does not only depend on
+the ``sweeping cron job'' but also on the removing of further messages.
+This is undesirable, because the real mechanism is hidden from the user
+and the consequences of further removals are not always obvious.
+Further more, the backup files are scattered within the whole mail
+storage, instead of being collected at one place.
+.P
+To improve the situation, the profile entry
+.Pe rmmproc
+(previously named
+.Pe Delete-Prog )
+was introduced, very early.
+It could be set to any command, which would care for the mail removal
+instead of taking the default action, described above.
+Refiling the to-be-removed files to some garbage folder was a common
+example. Nmh's man page
+.Mp rmm(1)
+proposes
+.Cl "refile +d
+to move messages to the garbage folder and
+.Cl "rm `mhpath +d all`
+the empty the garbage folder.
+Managing the message removal this way is a sane approach. It keeps
+the removed messages in one place, makes it easy to remove the backup
+files, and, most important, enables the user to use the tools of MH
+itself to operate on the removed messages. One can
+.Pn scan
+them,
+.Pn show
+them, and restore them with
+.Pn refile .
+There's no more
+need to use
+.Pn mhpath
+to switch over from MH tools to Unix tools \(en MH can do it all itself.
+.P
+This approach matches perfect with the concepts of MH, thus making
+it powerful. Hence, I made it the default. And even more, I also
+removed the old backup prefix approach, as it is clearly less powerful.
+Keeping unused alternative in the code is a bad choice as they likely
+gather bugs, by not being constantly tested. Also, the increased code
+size and more conditions crease the maintenance costs. By strictly
+converting to the trash folder approach, I simplified the code base.
+.Pn rmm
+calls
+.Pn refile
+internally to move the to-be-removed
+message to the trash folder (\c
+.Fn +trash
+by default). Messages
+there can be operated on like on any other message in the storage.
+The sweep clean, one can use
+.Cl "rmm \-unlink +trash a" ,
+where the
+.Sw \-unlink
+switch causes the files to be truly unliked instead
+of moved to the trash folder.
+
+
+.H2 "Path Notations
+.P
+foo
+
+
+.H2 "MIME Integration
+.P
+user-visible access to whole messages and MIME parts are inherently
+different
+
+
+.H2 "Of One Cast
+.P