# HG changeset patch # User markus schnalke # Date 1338546829 -7200 # Node ID 814c33b96d89398f77a2bab3e7de1c5544eca7de # Parent 8776101db595e18887e91ae67ca92b6572a40546 Restructured the content in ch03. diff -r 8776101db595 -r 814c33b96d89 ch03.roff --- 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 -foo +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 -bar +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. +.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 +.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. -.H1 "Removal of Code Relicts +.U2 "Removal of the MTS +.P + + +.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. +MIME + + +.H2 "Digital Cryptography .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. +Signing and encryption. + + +.H2 "Good Defaults .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. +foo + + + + +.H1 "Code style .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 +foo + + +.H2 "Standard Code .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 -.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. +POSIX -.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. +.H2 "Separation -.U2 "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. - - -.H1 "MH Directory Split +.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 +.H2 "Modularization .P -foo - -.H1 "Attachments +whatnowproc .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. -.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 -.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