1.1 --- a/ch03.roff	Sun May 20 22:10:22 2012 +0200
     1.2 +++ b/ch03.roff	Fri Jun 01 12:33:49 2012 +0200
     1.3 @@ -1,10 +1,159 @@
     1.4 -.H0 "Work Report
     1.5 +.H0 "Discussion
     1.6  .P
     1.7 -foo
     1.8 +This main chapter discusses the practical work done in the mmh project.
     1.9 +It is structured along the goals to achieve. The concrete work done
    1.10 +is described in the examples of how the general goals were achieved.
    1.11 +
    1.12 +
    1.13 +
    1.14 +
    1.15 +.H1 "Stream-lining
    1.16 +
    1.17 +
    1.18 +.H2 "Removal of non-MUA Tools
    1.19  .P
    1.20 -bar
    1.21 +MH had been considered an all-in-one system for mail handling.
    1.22 +The community around nmh has a similar understanding.
    1.23 +In fundamental difference, I believe that mmh should be a MUA but
    1.24 +nothing more. I believe that all-in-one mail systems are not the way
    1.25 +to go. There are excellent specialized MTAs, like Postfix;
    1.26 +there are specialized MDAs, like Procmail; there are specialized
    1.27 +MRAs, like Fetchmail. I believe it's best to use them instead of
    1.28 +providing the same function ourselves. Doing something well requires to
    1.29 +focus on this particular aspect or a small set of aspects. The more
    1.30 +it is possible to focus, the better the result in this particular
    1.31 +area will be. The limiting resource in Free Software community development
    1.32 +usually is human power. If the low development power is even parted
    1.33 +into multiple development areas, it will hardly be possible to 
    1.34 +compete with the specialists in the various fields. This is even
    1.35 +increased, given the small community \(en developers and users \(en
    1.36 +that MH-based mail systems have. In consequence, I believe that the
    1.37 +available resources should be concentrated at the point where MH is
    1.38 +most unique. This is clearly the MUA part.
    1.39 +.P
    1.40 +Several of nmh's tools were removed from mmh because they didn't
    1.41 +match the main focus of adding to the MUA's task.
    1.42 +.P
    1.43 +.Pn conflict
    1.44 +was removed because it is a mail system maintenance tool.
    1.45 +Besides, it also checks the
    1.46 +.Fn /etc/passwd
    1.47 +and
    1.48 +.Fn /etc/group
    1.49 +files.
    1.50 +The tool might be useful, but it should not be shipped with mmh.
    1.51 +.P
    1.52 +.Pn rcvtty
    1.53 +was removed because its usecase of writing to the user's terminal
    1.54 +on receiving of mail is hardly wanted today. If users like to be
    1.55 +informed of new mail, then using the shell's
    1.56 +.Ev MAILPATH
    1.57 +variable or different (graphical) notifications are likely more
    1.58 +appealing. Writing directly to other terminals is hardly ever wanted
    1.59 +today. If though one wants to have it this way, the standard tool
    1.60 +.Pn write
    1.61 +can be used in a way similar to:
    1.62 +.DS
    1.63 +scan -file - | write `id -un`
    1.64 +.DE
    1.65 +.P
    1.66 +When the new attachment system was introduced,
    1.67 +.Pn viamail
    1.68 +was removed because then
    1.69 +.Pn forw
    1.70 +could cover the task itself.
    1.71 +The wrapper program
    1.72 +.Pn sendfiles
    1.73 +was rewritten as a shell script to use
    1.74 +.Pn forw .
    1.75 +.P
    1.76 +.Pn msgchk
    1.77 +was removed as it became hardly useful when POP support was removed.
    1.78 +It is questionable if
    1.79 +.Pn msgchk
    1.80 +provides more information than:
    1.81 +.DS
    1.82 +ls -l /var/mail/meillo
    1.83 +.DE
    1.84 +It does separate between old and new mail, but that's not very
    1.85 +useful and can be found out with
    1.86 +.Pn stat (1)
    1.87 +too. A very small shell script could care for the form of output.
    1.88 +As mmh's inc only incorporates mail from the user's local maildrop
    1.89 +and thus no long data transfers are involved,
    1.90 +there's no need to check for new mail before incorporating it.
    1.91 +.P
    1.92 +.Pn msh
    1.93 +was removed because the tool was in conflict with the original
    1.94 +philosophy of MH. It provided an interactive shell to access the
    1.95 +features of MH. One major feature of MH is being a tool chest.
    1.96 +.Pn msh
    1.97 +wouldn't be just another shell, tailored to the needs of mail
    1.98 +handling, but one large program to have the MH tools built in.
    1.99 +It's main use was for accessing Bulletin Boards, which have seized to
   1.100 +be popular. Removing
   1.101 +.Pn msh ,
   1.102 +together with the truly obsolete programs
   1.103 +.Pn vmh
   1.104 +and
   1.105 +.Pn wmh ,
   1.106 +saved more than 7\|000 lines of C code \(en a major achievement.
   1.107  
   1.108 -.H1 "Removal of Code Relicts
   1.109 +.U2 "Removal of the MTS
   1.110 +.P
   1.111 +
   1.112 +
   1.113 +.H2 "mhshow show Merge
   1.114 +.P
   1.115 +Since the very beginning, already in the first concept paper,
   1.116 +.Pn show
   1.117 +had been MH's mail display program.
   1.118 +.Pn show
   1.119 +found out which pathnames the relevant messages had and invoked
   1.120 +.Pn mhl
   1.121 +then to let it render the content.
   1.122 +With the advent of MIME, this approach wasn't sufficient anymore.
   1.123 +MIME messages can consist of multiple parts, some of which aren't
   1.124 +directly displayable, and text content can be encoded in
   1.125 +foreign charsets.
   1.126 +.Pn show 's
   1.127 +simple approach and
   1.128 +.Pn mhl 's
   1.129 +limited display facilities couldn't cope with the task any longer.
   1.130 +Instead of extending these tools, new ones were written from scratch
   1.131 +and then added to the MH tool chest. Doing so is encouraged by the
   1.132 +tool chest approach. The new tools could be added without interfering
   1.133 +with the existing ones. This is great. It allowed MH to be the
   1.134 +first MUA to implement MIME.
   1.135 +.P
   1.136 +The new MIME features were added in form of the single program
   1.137 +.Pn mhn .
   1.138 +The command
   1.139 +.DS
   1.140 +mhn \-show 42
   1.141 +.DE
   1.142 +would show the MIME message numbered 42.
   1.143 +With the 1.0 release of nmh in February 1999, Richard Coleman finished
   1.144 +the split of
   1.145 +.Pn mhn
   1.146 +into a set of specialized programs, which together covered the
   1.147 +aspects of MIME. One of these resulting tools was
   1.148 +.Pn mhshow .
   1.149 +
   1.150 +
   1.151 +.H2 "Removal of Configure Options
   1.152 +.P
   1.153 +
   1.154 +.H2 "Removal of switches
   1.155 +.P
   1.156 +
   1.157 +
   1.158 +
   1.159 +
   1.160 +.H1 "Moderizing
   1.161 +
   1.162 +
   1.163 +.H2 "Removal of Code Relicts
   1.164  .P
   1.165  The code base of mmh originates from the late Seventies,
   1.166  had been extensively
   1.167 @@ -215,263 +364,36 @@
   1.168  common today.
   1.169  
   1.170  
   1.171 -.H1 "Removal of Tools
   1.172 +.H2 "Attachments
   1.173  .P
   1.174 -MH had been considered an all-in-one system for mail handling.
   1.175 -The community around nmh has a similar understanding.
   1.176 -In fundamental difference, I believe that mmh should be a MUA but
   1.177 -nothing more. I believe that all-in-one mail systems are not the way
   1.178 -to go. There are excellent specialized MTAs, like Postfix;
   1.179 -there are specialized MDAs, like Procmail; there are specialized
   1.180 -MRAs, like Fetchmail. I believe it's best to use them instead of
   1.181 -providing the same function ourselves. Doing something well requires to
   1.182 -focus on this particular aspect or a small set of aspects. The more
   1.183 -it is possible to focus, the better the result in this particular
   1.184 -area will be. The limiting resource in Free Software community development
   1.185 -usually is human power. If the low development power is even parted
   1.186 -into multiple development areas, it will hardly be possible to 
   1.187 -compete with the specialists in the various fields. This is even
   1.188 -increased, given the small community \(en developers and users \(en
   1.189 -that MH-based mail systems have. In consequence, I believe that the
   1.190 -available resources should be concentrated at the point where MH is
   1.191 -most unique. This is clearly the MUA part.
   1.192 +MIME
   1.193 +
   1.194 +
   1.195 +.H2 "Digital Cryptography
   1.196  .P
   1.197 -Several of nmh's tools were removed from mmh because they didn't
   1.198 -match the main focus of adding to the MUA's task.
   1.199 +Signing and encryption.
   1.200 +
   1.201 +
   1.202 +.H2 "Good Defaults
   1.203  .P
   1.204 -.Pn conflict
   1.205 -was removed because it is a mail system maintenance tool.
   1.206 -Besides, it also checks the
   1.207 -.Fn /etc/passwd
   1.208 -and
   1.209 -.Fn /etc/group
   1.210 -files.
   1.211 -The tool might be useful, but it should not be shipped with mmh.
   1.212 +foo
   1.213 +
   1.214 +
   1.215 +
   1.216 +
   1.217 +.H1 "Code style
   1.218  .P
   1.219 -.Pn rcvtty
   1.220 -was removed because its usecase of writing to the user's terminal
   1.221 -on receiving of mail is hardly wanted today. If users like to be
   1.222 -informed of new mail, then using the shell's
   1.223 -.Ev MAILPATH
   1.224 -variable or different (graphical) notifications are likely more
   1.225 -appealing. Writing directly to other terminals is hardly ever wanted
   1.226 -today. If though one wants to have it this way, the standard tool
   1.227 -.Pn write
   1.228 -can be used in a way similar to:
   1.229 -.DS
   1.230 -scan -file - | write `id -un`
   1.231 -.DE
   1.232 +foo
   1.233 +
   1.234 +
   1.235 +.H2 "Standard Code
   1.236  .P
   1.237 -When the new attachment system was introduced,
   1.238 -.Pn viamail
   1.239 -was removed because then
   1.240 -.Pn forw
   1.241 -could cover the task itself.
   1.242 -The wrapper program
   1.243 -.Pn sendfiles
   1.244 -was rewritten as a shell script to use
   1.245 -.Pn forw .
   1.246 -.P
   1.247 -.Pn msgchk
   1.248 -was removed as it became hardly useful when POP support was removed.
   1.249 -It is questionable if
   1.250 -.Pn msgchk
   1.251 -provides more information than:
   1.252 -.DS
   1.253 -ls -l /var/mail/meillo
   1.254 -.DE
   1.255 -It does separate between old and new mail, but that's not very
   1.256 -useful and can be found out with
   1.257 -.Pn stat (1)
   1.258 -too. A very small shell script could care for the form of output.
   1.259 -As mmh's inc only incorporates mail from the user's local maildrop
   1.260 -and thus no long data transfers are involved,
   1.261 -there's no need to check for new mail before incorporating it.
   1.262 -.P
   1.263 -.Pn msh
   1.264 -was removed because the tool was in conflict with the original
   1.265 -philosophy of MH. It provided an interactive shell to access the
   1.266 -features of MH. One major feature of MH is being a tool chest.
   1.267 -.Pn msh
   1.268 -wouldn't be just another shell, tailored to the needs of mail
   1.269 -handling, but one large program to have the MH tools built in.
   1.270 -It's main use was for accessing Bulletin Boards, which have seized to
   1.271 -be popular. Removing
   1.272 -.Pn msh ,
   1.273 -together with the truly obsolete programs
   1.274 -.Pn vmh
   1.275 -and
   1.276 -.Pn wmh ,
   1.277 -saved more than 7\|000 lines of C code \(en a major achievement.
   1.278 +POSIX
   1.279  
   1.280  
   1.281 -.H1 "Draft and Trash Folders
   1.282 -.U2 "Draft Folder
   1.283 -.P
   1.284 -Historically, MH provided exactly one draft message, named
   1.285 -.Fn draft
   1.286 -and
   1.287 -being located in the MH directory. When starting to compose another message
   1.288 -before the former one was sent, the user had been questioned whether to use,
   1.289 -refile or replace the old draft. Working on multiple drafts at the same time
   1.290 -was impossible. One could only work on them in alteration by refiling the
   1.291 -previous one to some directory and fetching some other one for reediting. 
   1.292 -This manual draft management needed to be done each time the user wanted
   1.293 -to switch between editing one draft to editing another.
   1.294 -.P
   1.295 -To allow true parallel editing of drafts, in a straight forward way, the
   1.296 -draft folder facility exists. It had been introduced already in July 1984
   1.297 -by Marshall T. Rose. The facility was deactivated by default.
   1.298 -Even in nmh, the draft folder facility remained deactivated by default.
   1.299 -At least, Richard Coleman added the man page
   1.300 -.Mp mh-draft(5)
   1.301 -to document
   1.302 -the feature well.
   1.303 -.P
   1.304 -The only advantage of not using the draft folder facility is the static
   1.305 -name of the draft file. This could be an issue for MH frontends like mh-e.
   1.306 -But as they likely want to provide working on multiple drafts in parallel,
   1.307 -the issue is only concerning compatibility. The aim of nmh to stay compatible
   1.308 -prevented the default activation of the draft folder facility.
   1.309 -.P
   1.310 -On the other hand, a draft folder is the much more natural concept than
   1.311 -a draft message. MH's mail storage consists of folders and messages,
   1.312 -the messages named with ascending numbers. A draft message breaks with this
   1.313 -concept by introducing a message in a file named
   1.314 -.Fn draft .
   1.315 -This draft
   1.316 -message is special. It can not be simply listed with the available tools,
   1.317 -but instead requires special switches. I.e. corner-cases were
   1.318 -introduced. A draft folder, in contrast, does not introduce such
   1.319 -corner-cases. The available tools can operate on the messages within that
   1.320 -folder like on any messages within any mail folders. The only difference
   1.321 -is the fact that the default folder for
   1.322 -.Pn send
   1.323 -is the draft folder,
   1.324 -instead of the current folder, like for all other tools.
   1.325 -.P
   1.326 -The trivial part of the change was activating the draft folder facility
   1.327 -by default and setting a default name for this folder. Obviously, I chose
   1.328 -the name
   1.329 -.Fn +drafts .
   1.330 -This made the
   1.331 -.Sw \-draftfolder
   1.332 -and
   1.333 -.Sw \-draftmessage
   1.334 -switches useless, and I could remove them.
   1.335 -The more difficult but also the part that showed the real improvement,
   1.336 -was updating the tools to the new concept.
   1.337 -.Sw \-draft
   1.338 -switches could
   1.339 -be dropped, as operating on a draft message became indistinguishable to
   1.340 -operating on any other message for the tools.
   1.341 -.Pn comp
   1.342 -still has its
   1.343 -.Sw \-use
   1.344 -switch for switching between its two modes: (1) Compose a new
   1.345 -draft, possibly by taking some existing message as a form. (2) Modify
   1.346 -an existing draft. In either case, the behavior of
   1.347 -.Pn comp is
   1.348 -deterministic. There is no more need to query the user. I consider this
   1.349 -a major improvement. By making
   1.350 -.Pn send
   1.351 -simply operate on the current
   1.352 -message in the draft folder by default, with message and folder both
   1.353 -overridable by specifying them on the command line, it is now possible
   1.354 -to send a draft anywhere within the storage by simply specifying its folder
   1.355 -and name.
   1.356 -.P
   1.357 -All theses changes converted special cases to regular cases, thus
   1.358 -simplifying the tools and increasing the flexibility.
   1.359 +.H2 "Separation
   1.360  
   1.361 -.U2 "Trash Folder
   1.362 -.P
   1.363 -Similar to the situation for drafts is the situation for removed messages.
   1.364 -Historically, a message was deleted by renaming. A specific
   1.365 -\fIbackup prefix\fP, often comma (\c
   1.366 -.Fn , )
   1.367 -or hash (\c
   1.368 -.Fn # ),
   1.369 -being prepended to the file name. Thus, MH wouldn't recognize the file
   1.370 -as a message anymore, as only files whose name consists of digits only
   1.371 -are treated as messages. The removed messages remained as files in the
   1.372 -same directory and needed some maintenance job to truly delete them after
   1.373 -some grace time. Usually, by running a command similar to
   1.374 -.DS
   1.375 -find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
   1.376 -.DE
   1.377 -in a cron job. Within the grace time interval
   1.378 -the original message could be restored by stripping the
   1.379 -the backup prefix from the file name. If however, the last message of
   1.380 -a folder is been removed \(en say message
   1.381 -.Fn 6
   1.382 -becomes file
   1.383 -.Fn ,6
   1.384 -\(en and a new message enters the same folder, thus the same
   1.385 -numbered being given again \(en in our case
   1.386 -.Fn 6
   1.387 -\(en, if that one
   1.388 -is removed too, then the backup of the former message gets overwritten.
   1.389 -Thus, the ability to restore removed messages does not only depend on
   1.390 -the ``sweeping cron job'' but also on the removing of further messages.
   1.391 -This is undesirable, because the real mechanism is hidden from the user
   1.392 -and the consequences of further removals are not always obvious.
   1.393 -Further more, the backup files are scattered within the whole mail
   1.394 -storage, instead of being collected at one place.
   1.395 -.P
   1.396 -To improve the situation, the profile entry
   1.397 -.Pe rmmproc
   1.398 -(previously named
   1.399 -.Pe Delete-Prog )
   1.400 -was introduced, very early.
   1.401 -It could be set to any command, which would care for the mail removal
   1.402 -instead of taking the default action, described above.
   1.403 -Refiling the to-be-removed files to some garbage folder was a common
   1.404 -example. Nmh's man page
   1.405 -.Mp rmm(1)
   1.406 -proposes
   1.407 -.Cl "refile +d
   1.408 -to move messages to the garbage folder and
   1.409 -.Cl "rm `mhpath +d all`
   1.410 -the empty the garbage folder.
   1.411 -Managing the message removal this way is a sane approach. It keeps
   1.412 -the removed messages in one place, makes it easy to remove the backup
   1.413 -files, and, most important, enables the user to use the tools of MH
   1.414 -itself to operate on the removed messages. One can
   1.415 -.Pn scan
   1.416 -them,
   1.417 -.Pn show
   1.418 -them, and restore them with
   1.419 -.Pn refile .
   1.420 -There's no more
   1.421 -need to use
   1.422 -.Pn mhpath
   1.423 -to switch over from MH tools to Unix tools \(en MH can do it all itself.
   1.424 -.P
   1.425 -This approach matches perfect with the concepts of MH, thus making
   1.426 -it powerful. Hence, I made it the default. And even more, I also
   1.427 -removed the old backup prefix approach, as it is clearly less powerful.
   1.428 -Keeping unused alternative in the code is a bad choice as they likely
   1.429 -gather bugs, by not being constantly tested. Also, the increased code
   1.430 -size and more conditions crease the maintenance costs. By strictly
   1.431 -converting to the trash folder approach, I simplified the code base.
   1.432 -.Pn rmm
   1.433 -calls
   1.434 -.Pn refile
   1.435 -internally to move the to-be-removed
   1.436 -message to the trash folder (\c
   1.437 -.Fn +trash
   1.438 -by default). Messages
   1.439 -there can be operated on like on any other message in the storage.
   1.440 -The sweep clean, one can use
   1.441 -.Cl "rmm \-unlink +trash a" ,
   1.442 -where the
   1.443 -.Sw \-unlink
   1.444 -switch causes the files to be truly unliked instead
   1.445 -of moved to the trash folder.
   1.446 -
   1.447 -
   1.448 -.H1 "MH Directory Split
   1.449 +.U2 "MH Directory Split
   1.450  .P
   1.451  In MH and nmh, a personal setup had consisted of two parts:
   1.452  The MH profile, named
   1.453 @@ -563,77 +485,203 @@
   1.454  split between mail storage and personal configuration files.
   1.455  
   1.456  
   1.457 -.H1 "Path Notations
   1.458 +.H2 "Modularization
   1.459  .P
   1.460 -foo
   1.461 -
   1.462 -.H1 "Attachments
   1.463 +whatnowproc
   1.464  .P
   1.465 -foo
   1.466 -
   1.467 -.H1 "mhshow to show Transition
   1.468 -.P
   1.469 -Since the very beginning, already in the first concept paper,
   1.470 -.Pn show
   1.471 -had been MH's mail display program.
   1.472 -.Pn show
   1.473 -found out which pathnames the relevant messages had and invoked
   1.474 -.Pn mhl
   1.475 -then to let it render the content.
   1.476 -With the advent of MIME, this approach wasn't sufficient anymore.
   1.477 -MIME messages can consist of multiple parts, some of which aren't
   1.478 -directly displayable, and text content can be encoded in
   1.479 -foreign charsets.
   1.480 -.Pn show 's
   1.481 -simple approach and
   1.482 -.Pn mhl 's
   1.483 -limited display facilities couldn't cope with the task any longer.
   1.484 -Instead of extending these tools, new ones were written from scratch
   1.485 -and then added to the MH tool chest. Doing so is encouraged by the
   1.486 -tool chest approach. The new tools could be added without interfering
   1.487 -with the existing ones. This is great. It allowed MH to be the
   1.488 -first MUA to implement MIME.
   1.489 -.P
   1.490 -The new MIME features were added in form of the single program
   1.491 -.Pn mhn .
   1.492 -The command
   1.493 -.DS
   1.494 -mhn \-show 42
   1.495 -.DE
   1.496 -would show the MIME message numbered 42.
   1.497 -With the 1.0 release of nmh in February 1999, Richard Coleman finished
   1.498 -the split of
   1.499 -.Pn mhn
   1.500 -into a set of specialized programs, which together covered the
   1.501 -aspects of MIME. One of these resulting tools was
   1.502 -.Pn mhshow .
   1.503 -
   1.504 -
   1.505 -.H1 "Blind Carbon Copies
   1.506 -.P
   1.507 -foo
   1.508 -
   1.509 -.H1 "Good Defaults
   1.510 -.P
   1.511 -foo
   1.512 -
   1.513 -.H1 "Modularization
   1.514 -.P
   1.515 -foo
   1.516 -
   1.517 -.H1 "Code style
   1.518 -.P
   1.519 -foo
   1.520 -
   1.521 -
   1.522 -
   1.523 -(e.g. the
   1.524 -user-visible access to whole messages and MIME parts are inherently
   1.525 -different).
   1.526 -
   1.527  The \fIMH library\fP
   1.528  .Fn libmh.a
   1.529  collects a bunch of standard functions that many of the MH tools need,
   1.530  like reading the profile or context files.
   1.531  This doesn't hurt the separation.
   1.532  
   1.533 +
   1.534 +.H2 "Style
   1.535 +.P
   1.536 +Code layout, goto, ...
   1.537 +
   1.538 +
   1.539 +
   1.540 +
   1.541 +.H1 "Concept Exploitation/Homogeniety
   1.542 +
   1.543 +
   1.544 +.H2 "Draft Folder
   1.545 +.P
   1.546 +Historically, MH provided exactly one draft message, named
   1.547 +.Fn draft
   1.548 +and
   1.549 +being located in the MH directory. When starting to compose another message
   1.550 +before the former one was sent, the user had been questioned whether to use,
   1.551 +refile or replace the old draft. Working on multiple drafts at the same time
   1.552 +was impossible. One could only work on them in alteration by refiling the
   1.553 +previous one to some directory and fetching some other one for reediting. 
   1.554 +This manual draft management needed to be done each time the user wanted
   1.555 +to switch between editing one draft to editing another.
   1.556 +.P
   1.557 +To allow true parallel editing of drafts, in a straight forward way, the
   1.558 +draft folder facility exists. It had been introduced already in July 1984
   1.559 +by Marshall T. Rose. The facility was deactivated by default.
   1.560 +Even in nmh, the draft folder facility remained deactivated by default.
   1.561 +At least, Richard Coleman added the man page
   1.562 +.Mp mh-draft(5)
   1.563 +to document
   1.564 +the feature well.
   1.565 +.P
   1.566 +The only advantage of not using the draft folder facility is the static
   1.567 +name of the draft file. This could be an issue for MH frontends like mh-e.
   1.568 +But as they likely want to provide working on multiple drafts in parallel,
   1.569 +the issue is only concerning compatibility. The aim of nmh to stay compatible
   1.570 +prevented the default activation of the draft folder facility.
   1.571 +.P
   1.572 +On the other hand, a draft folder is the much more natural concept than
   1.573 +a draft message. MH's mail storage consists of folders and messages,
   1.574 +the messages named with ascending numbers. A draft message breaks with this
   1.575 +concept by introducing a message in a file named
   1.576 +.Fn draft .
   1.577 +This draft
   1.578 +message is special. It can not be simply listed with the available tools,
   1.579 +but instead requires special switches. I.e. corner-cases were
   1.580 +introduced. A draft folder, in contrast, does not introduce such
   1.581 +corner-cases. The available tools can operate on the messages within that
   1.582 +folder like on any messages within any mail folders. The only difference
   1.583 +is the fact that the default folder for
   1.584 +.Pn send
   1.585 +is the draft folder,
   1.586 +instead of the current folder, like for all other tools.
   1.587 +.P
   1.588 +The trivial part of the change was activating the draft folder facility
   1.589 +by default and setting a default name for this folder. Obviously, I chose
   1.590 +the name
   1.591 +.Fn +drafts .
   1.592 +This made the
   1.593 +.Sw \-draftfolder
   1.594 +and
   1.595 +.Sw \-draftmessage
   1.596 +switches useless, and I could remove them.
   1.597 +The more difficult but also the part that showed the real improvement,
   1.598 +was updating the tools to the new concept.
   1.599 +.Sw \-draft
   1.600 +switches could
   1.601 +be dropped, as operating on a draft message became indistinguishable to
   1.602 +operating on any other message for the tools.
   1.603 +.Pn comp
   1.604 +still has its
   1.605 +.Sw \-use
   1.606 +switch for switching between its two modes: (1) Compose a new
   1.607 +draft, possibly by taking some existing message as a form. (2) Modify
   1.608 +an existing draft. In either case, the behavior of
   1.609 +.Pn comp is
   1.610 +deterministic. There is no more need to query the user. I consider this
   1.611 +a major improvement. By making
   1.612 +.Pn send
   1.613 +simply operate on the current
   1.614 +message in the draft folder by default, with message and folder both
   1.615 +overridable by specifying them on the command line, it is now possible
   1.616 +to send a draft anywhere within the storage by simply specifying its folder
   1.617 +and name.
   1.618 +.P
   1.619 +All theses changes converted special cases to regular cases, thus
   1.620 +simplifying the tools and increasing the flexibility.
   1.621 +
   1.622 +
   1.623 +.H2 "Trash Folder
   1.624 +.P
   1.625 +Similar to the situation for drafts is the situation for removed messages.
   1.626 +Historically, a message was deleted by renaming. A specific
   1.627 +\fIbackup prefix\fP, often comma (\c
   1.628 +.Fn , )
   1.629 +or hash (\c
   1.630 +.Fn # ),
   1.631 +being prepended to the file name. Thus, MH wouldn't recognize the file
   1.632 +as a message anymore, as only files whose name consists of digits only
   1.633 +are treated as messages. The removed messages remained as files in the
   1.634 +same directory and needed some maintenance job to truly delete them after
   1.635 +some grace time. Usually, by running a command similar to
   1.636 +.DS
   1.637 +find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
   1.638 +.DE
   1.639 +in a cron job. Within the grace time interval
   1.640 +the original message could be restored by stripping the
   1.641 +the backup prefix from the file name. If however, the last message of
   1.642 +a folder is been removed \(en say message
   1.643 +.Fn 6
   1.644 +becomes file
   1.645 +.Fn ,6
   1.646 +\(en and a new message enters the same folder, thus the same
   1.647 +numbered being given again \(en in our case
   1.648 +.Fn 6
   1.649 +\(en, if that one
   1.650 +is removed too, then the backup of the former message gets overwritten.
   1.651 +Thus, the ability to restore removed messages does not only depend on
   1.652 +the ``sweeping cron job'' but also on the removing of further messages.
   1.653 +This is undesirable, because the real mechanism is hidden from the user
   1.654 +and the consequences of further removals are not always obvious.
   1.655 +Further more, the backup files are scattered within the whole mail
   1.656 +storage, instead of being collected at one place.
   1.657 +.P
   1.658 +To improve the situation, the profile entry
   1.659 +.Pe rmmproc
   1.660 +(previously named
   1.661 +.Pe Delete-Prog )
   1.662 +was introduced, very early.
   1.663 +It could be set to any command, which would care for the mail removal
   1.664 +instead of taking the default action, described above.
   1.665 +Refiling the to-be-removed files to some garbage folder was a common
   1.666 +example. Nmh's man page
   1.667 +.Mp rmm(1)
   1.668 +proposes
   1.669 +.Cl "refile +d
   1.670 +to move messages to the garbage folder and
   1.671 +.Cl "rm `mhpath +d all`
   1.672 +the empty the garbage folder.
   1.673 +Managing the message removal this way is a sane approach. It keeps
   1.674 +the removed messages in one place, makes it easy to remove the backup
   1.675 +files, and, most important, enables the user to use the tools of MH
   1.676 +itself to operate on the removed messages. One can
   1.677 +.Pn scan
   1.678 +them,
   1.679 +.Pn show
   1.680 +them, and restore them with
   1.681 +.Pn refile .
   1.682 +There's no more
   1.683 +need to use
   1.684 +.Pn mhpath
   1.685 +to switch over from MH tools to Unix tools \(en MH can do it all itself.
   1.686 +.P
   1.687 +This approach matches perfect with the concepts of MH, thus making
   1.688 +it powerful. Hence, I made it the default. And even more, I also
   1.689 +removed the old backup prefix approach, as it is clearly less powerful.
   1.690 +Keeping unused alternative in the code is a bad choice as they likely
   1.691 +gather bugs, by not being constantly tested. Also, the increased code
   1.692 +size and more conditions crease the maintenance costs. By strictly
   1.693 +converting to the trash folder approach, I simplified the code base.
   1.694 +.Pn rmm
   1.695 +calls
   1.696 +.Pn refile
   1.697 +internally to move the to-be-removed
   1.698 +message to the trash folder (\c
   1.699 +.Fn +trash
   1.700 +by default). Messages
   1.701 +there can be operated on like on any other message in the storage.
   1.702 +The sweep clean, one can use
   1.703 +.Cl "rmm \-unlink +trash a" ,
   1.704 +where the
   1.705 +.Sw \-unlink
   1.706 +switch causes the files to be truly unliked instead
   1.707 +of moved to the trash folder.
   1.708 +
   1.709 +
   1.710 +.H2 "Path Notations
   1.711 +.P
   1.712 +foo
   1.713 +
   1.714 +
   1.715 +.H2 "MIME Integration
   1.716 +.P
   1.717 +user-visible access to whole messages and MIME parts are inherently
   1.718 +different
   1.719 +
   1.720 +
   1.721 +.H2 "Of One Cast
   1.722 +.P