docs/master
view ch03.roff @ 66:4c9f4d05d90e
Rework and extension of text from yesterday.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Sat, 02 Jun 2012 10:32:26 +0200 |
| parents | abbaca05ee8e |
| children | f80ced4e749b |
line source
1 .H0 "Discussion
2 .P
3 This main chapter discusses the practical work done in the mmh project.
4 It is structured along the goals to achieve. The concrete work done
5 is described in the examples of how the general goals were achieved.
10 .H1 "Stream-lining
12 .P
13 MH had been considered an all-in-one system for mail handling.
14 The community around nmh has a similar understanding.
15 In fundamental difference, I believe that mmh should be a MUA but
16 nothing more. I believe that all-in-one mail systems are not the way
17 to go. There are excellent specialized MTAs, like Postfix;
18 there are specialized MDAs, like Procmail; there are specialized
19 MRAs, like Fetchmail. I believe it's best to use them instead of
20 providing the same function ourselves. Doing something well requires to
21 focus on this particular aspect or a small set of aspects. The more
22 it is possible to focus, the better the result in this particular
23 area will be. The limiting resource in Free Software community development
24 usually is human power. If the low development power is even parted
25 into multiple development areas, it will hardly be possible to
26 compete with the specialists in the various fields. This is even
27 increased, given the small community \(en developers and users \(en
28 that MH-based mail systems have. In consequence, I believe that the
29 available resources should be concentrated at the point where MH is
30 most unique. This is clearly the MUA part.
31 .P
32 The goal for mmh was to remove peripheral parts and stream-line
33 it for the MUA task.
36 .H2 "Removal of Mail Transfer Facilities
37 .P
38 In contrast to nmh, which also provides mail submission and mail retrieval
39 facilities, mmh is a MUA only.
40 This general difference in the view on the character of nmh
41 strongly supported the development of mmh.
42 Removing the mail transfer facilities had been the first work task
43 for the mmh project.
44 .P
45 The MSA is called \fIMessage Transfer Service\fP (MTS) in nmh.
46 The facility establishes TCP/IP connections and speaks SMTP to submit
47 messages for relay to the outside world.
48 This part is implemented in the
49 .Pn post
50 command.
51 Demanded by the changes in
52 emailing, this part of nmh required changes in the last years.
53 Encrypted connections needed to be supported, hence SASL was introduced
54 into nmh. This added complexity to the nmh without improving it in
55 its core functions. Also, keeping up with recent developments in
56 this field needs requires development power and specialists.
57 Mmh cuts this whole facility off and depends on an external MTA instead.
58 The only outgoing interface available to mmh is the
59 .Pn sendmail
60 command.
61 Almost any MTA provides a
62 .Pn sendmail
63 command.
64 It not, any program can be substituted if it reads the
65 message from the standard input, extracts the recipient addresses
66 from the message header and does not conflict
67 with sendmail-specific command line arguments.
68 .P
69 To retrieve mail, the
70 .Pn inc
71 command in nmh has the ability to establish TCP/IP connections
72 and speaks POP3 to retrieve mail from remote servers.
73 As with mail submission, here encrypted connections are required
74 today, thus SASL support was added.
75 As POP3 is superseded by IMAP more and more, support for message
76 retrieval through IMAP will become necessary to be added soon.
77 Mmh has no support for retrieving mail from remote locations.
78 It depends on an external tool to cover this task.
79 There are two ways for messages to enter mmh's mail storage:
80 Incorporate them with
81 .Pn inc
82 from the system maildrop, or with
83 .Pn rcvstore
84 from the standard input.
85 In consequence, mmh has not any longer networking code
86 and thus does no more need to do transfer encryption and authentication.
87 Two large functional units are removed.
88 .P
89 With the removal of the MSA and MRA, mmh converted from an all-in-one
90 mail system to being only a MUA.
91 Following the Unix philosophy, it focuses on one job and to do that well.
92 Now, of course, mmh depends on third-party software.
93 An external MTA/MSA is required to transfer mail to the outside world;
94 an external MRA is required to retrieve mail from remote machines.
95 There exist excellent implementations of such software,
96 which do this specific task likely much better than the internal
97 versions of nmh do it. Also, this provides the choice for the best
98 suiting one of the available implementation.
99 .P
100 As it had already been possible to use an external MSA or MRA,
101 why not keep the internal version for convenience?
102 If this would question the sense in having a fall-back pager in all
103 the command line tools, in case
104 .Pn more
105 or
106 .Pn less
107 wouldn't be available, the answer is intuitively seen.
108 Now, an MSA or MRA is clearly more complex than a text pager, but
109 still the concept holds: If programs become complex, split them;
110 if projects become complex, split them.
111 Complexity is demanded by the problem to solve. Decades ago,
112 emailing had been small and simple.
113 (Remember,
114 .Pn /bin/mail
115 had once covered anything there was to email and still had been small.)
116 As the complexity in emailing increased, MH remainded mostly unchanged.
117 Nontheless, in nmh the POP server, which the original MH had included,
118 was removed. Now is the time to take one step further and remove
119 the MSA and MRA.
120 Not only does it decrease the code amount of the project,
121 but more important, it removes the whole field of message transfer
122 with all its implications from the project.
123 .P
124 If a project needs some kind of function, there's always the choice
125 between implementing the the function in the project directly or
126 depending on a library that provides the function or depending on
127 a program that provides the function.
128 Whereas adding the function directly to the project increases the
129 code size most, it makes the project most independent.
130 On the other end, interfacing external programs keeps the interface
131 smallest, but the depencency highest.
132 Using a library is in the middle.
133 Adding the function directly to the project is a bad choice for
134 any function of higher complexity, unless it's not available in other ways.
135 Hence, the dependencies only change in kind, not in their existence.
136 In mmh, library dependencies on
137 .Pn libsasl2
138 and
139 .Pn libcrypto /\c
140 .Pn libssl
141 were treated against program dependencies on an MSA and an MRA.
142 Besides program dependencies providing the stronger separation
143 and being more flexible, they also allowed
144 over 6\|000 lines of code to be removed from mmh.
145 This made mmh's code base about 12\|% smaller.
146 Reducing the projects code size by such an amount without actually
147 losing function is a convincing argument.
148 .P
149 Users of MH should have not problem to set up an external MSA and MRA.
150 Also, the popular MSAs and MRAs have large communities and a lot
151 of documentation available.
152 .P
153 Choices for MSAs range from the full-featured
154 .I Postfix
155 over mid-size solutions like
156 .I masqmail
157 and
158 .I dma
159 to small forwarders like
160 .I ssmtp
161 and
162 .I nullmailer .
163 Choices for MRAs include
164 .I fetchmail ,
165 .I getmail ,
166 .I mpop
167 and
168 .I fdm .
171 .H2 "Removal of non-MUA Tools
172 .P
173 Some of nmh's tools were removed from mmh because they didn't
174 match the main focus of adding to the MUA's task.
175 .BU
176 .Pn conflict
177 was removed because it is a mail system maintenance tool.
178 Besides, it even checks
179 .Fn /etc/passwd
180 and
181 .Fn /etc/group
182 for consistency, which has nothing at all to do with emailing.
183 The tool might be useful, but it should not be shipped with mmh.
184 .BU
185 .Pn rcvtty
186 was removed because its usecase of writing to the user's terminal
187 on receiving of mail is hardly wanted today. If users like to be
188 informed of new mail, then using the shell's
189 .Ev MAILPATH
190 variable or graphical notifications are likely more
191 appealing.
192 Writing directly to a terminals is hardly ever wanted today.
193 If though one wants to have it this way, the standard tool
194 .Pn write
195 can be used in a way similar to:
196 .DS
197 scan -file - | write `id -un`
198 .DE
199 .BU
200 .Pn viamail
201 was removed when the new attachment system was introduced, because
202 .Pn forw
203 could can now the task itself.
204 The program
205 .Pn sendfiles
206 was rewritten as a shell script wrapper around
207 .Pn forw .
208 .BU
209 .Pn msgchk
210 was removed, because it lost its usefulness when POP support was removed.
211 .Pn msgchk
212 provides hardly more information than:
213 .DS
214 ls -l /var/mail/meillo
215 .DE
216 It does separate between old and new mail, but that's merely a detail
217 and can be done with
218 .Pn stat (1)
219 too.
220 A very small shell script could be written to output the information
221 in a convenient way, if truly necessary.
222 As mmh's inc only incorporates mail from the user's local maildrop
223 and thus no data transfers over slow networks are involved,
224 there's hardly need to check for new mail before incorporating it.
225 .BU
226 .Pn msh
227 was removed because the tool was in conflict with the
228 philosophy of MH. It provided an interactive shell to access the
229 features of MH. One major feature of MH is being a tool chest.
230 .Pn msh
231 wouldn't be just another shell, tailored to the needs of mail
232 handling, but one large program to have the MH tools built in.
233 It's main use was for accessing Bulletin Boards, which have seized to
234 be popular.
235 .P
236 Removing
237 .Pn msh ,
238 together with the truly obsolete code relicts
239 .Pn vmh
240 and
241 .Pn wmh ,
242 saved more than 7\|000 lines of C code \(en
243 about 15\|% of the project's original source code amount.
244 Having the same functionality in less code (with equal readability,
245 of course) is an advantage.
246 Less code means less bugs and less maintenance work.
247 If
248 .Pn rcvtty
249 and
250 .Pn msgchk
251 are rarely used and can be implemented in different ways,
252 then why should one keep them?
253 .Pn viamail 's
254 use case is now partly obsolete and partly covered by
255 .Pn forw ,
256 hence there's no reason to still have
257 .Pn viamail
258 around.
259 .Pn conflict
260 is not related with the mail client, and
261 .Pn msh
262 conflicts with the basic concept of MH.
263 Both tools could still be useful, but not as part of mmh.
264 .P
265 It is a design goal of mmh to remove those parts that are rarely used.
266 The project shall become more stream-lined.
267 Rarely used and loosely related tools distract from the lean appearance.
268 They require maintenance cost without adding to the core task.
269 Therefore they were removed.
272 .H2 "Merge of \f(CWshow\fP and \f(CWmhshow\fP
273 .P
274 Since the very beginning, already in the first concept paper,
275 .Pn show
276 had been MH's message display program.
277 .Pn show
278 found out which pathnames the relevant messages had and invoked
279 .Pn mhl
280 then to have the content formated.
281 With the advent of MIME, this approach wasn't sufficient anymore.
282 MIME messages can consist of multiple parts, some of which aren't
283 directly displayable, and text content might be encoded in
284 foreign charsets.
285 .Pn show 's
286 simple approach and
287 .Pn mhl 's
288 limited display facilities couldn't cope with the task any longer.
289 .P
290 Instead of extending these tools, new ones were written from scratch
291 and then added to the MH tool chest. Doing so is encouraged by the
292 tool chest approach. The new tools could be added without interfering
293 with the existing ones. This is great. The ease of adding new tools
294 even made MH the first MUA to implement MIME.
295 .P
296 First, the new MIME features were added in form of the single program
297 .Pn mhn .
298 The command
299 .Cl "mhn \-show 42
300 would show the MIME message numbered 42.
301 With the 1.0 release of nmh in February 1999, Richard Coleman finished
302 the split of
303 .Pn mhn
304 into a set of specialized programs, which together covered the
305 multiple aspects of MIME. One of these resulting tools was
306 .Pn mhshow .
307 .Pn mhshow
308 resembled the
309 .Cl "mhn \-show
310 call.
311 .P
314 .H2 "Removal of Configure Options
315 .P
318 .H2 "Removal of switches
319 .P
324 .H1 "Moderizing
327 .H2 "Removal of Code Relicts
328 .P
329 The code base of mmh originates from the late Seventies,
330 had been extensively
331 worked on in the mid Eighties, and had been partly reorganized and extended
332 in the Nineties. Relicts of all those times had gathered in the code base.
333 My goal was to remove any ancient code parts. One part of the task was
334 converting obsolete code constructs to standard constructs, the other part
335 was dropping obsolete functions.
336 .P
337 As I'm not even thirty years old and have no more than seven years of
338 Unix experience, I needed to learn about the history in retrospective.
339 Older people likely have used those ancient constructs themselves
340 and have suffered from their incompatibilities and have longed for
341 standardization. Unfortunately, I have only read that others had done so.
342 This put me in a much more difficult positions when working on the old
343 code. I needed to recherche what other would have known by heart from
344 experience. All my programming experience comes from a time past ANSI C
345 and past POSIX. Although I knew about the times before, I took the
346 current state implicitly for granted most of the time.
347 .P
348 Being aware of
349 these facts, I rather let people with more historic experience solve the
350 task of converting the ancient code constructs to standardized ones.
351 Luckily, Lyndon Nerenberg focused on this task at the nmh project.
352 He converted large parts of the code to POSIX constructs, removing
353 the conditionals compilation for now standardized features.
354 I'm thankful for this task being solved. I only pulled the changes into
355 mmh.
356 .P
357 The other task \(en dropping ancient functionality to remove old code \(en
358 I did myself, though. My position to strip mmh to the bare minimum of
359 frequently used features is much more revolutional than the nmh community
360 likes it. Without the need to justify my decisions, I was able to quickly
361 remove functionality I considered ancient.
362 The need to discuss my decisions with
363 peers likely would have slowed this process down. Of course, I researched
364 if a particular feature really should be dropped. Having not had any
365 contact to this feature within my computer life was a first indicator to
366 drop it, but I also asked others and searched the literature for modern
367 usage of the feature. If it appeared to be truly ancient, I dropped it.
368 The reason for dropping is always part of the commit message in the
369 version control system. Thus, it is easy for others to check their
370 view on the topic with mine and possibly to argue for reinclusion.
372 .U2 "MMDF maildrop support
373 .P
374 I did drop any support for the MMDF maildrop format. This type of format
375 is conceptionally similar to the mbox format, but uses four bytes with
376 value 1 (\fL^A^A^A^A\fP) as message delimiter,
377 instead of the string ``\fLFrom\ \fP''.
378 Due to the similarity and mbox being the de-facto standard maildrop
379 format on Unix, but also due to the larger influence of Sendmail than MMDF,
380 the MMDF maildrop format had vanished.
381 .P
382 The simplifications within the code were only moderate. Switches could
383 be removed from tools like
384 .L packf ,
385 which generate packed mailboxes. Only one packed mailbox format remained:
386 mbox.
387 The most important changes affect the equally named mail parsing routine in
388 .L sbr/m_getfld.c .
389 The direct MMDF code had been removed, but as now only one packed mailbox
390 format is left, code structure simplifications are likely possible.
391 The reason why they are still outstanding is the heavily optimized code
392 of
393 .Fu m_getfld() .
394 Changes beyond a small local scope \(en
395 which restructuring in its core is \(en cause a high risk of damaging
396 the intricate workings of the optimized code. This problem is know
397 to the developers of nmh, too. They also avoid touching this minefield
398 if possible.
400 .U2 "UUCP Bang Paths
401 .P
402 More questionably than the former topic is the removal of support for the
403 UUCP bang path address style. However, the user may translate the bang
404 paths on retrieval to Internet addresses and the other way on posting
405 messages. The former can be done my an MDA like procmail; the latter
406 by a sendmail wrapper. This would ensure that any address handling would
407 work as expected. However, it might just work well without any
408 such modifications, as mmh does not touch addresses much, in general.
409 But I can't ensure as I have never used an environment with bang paths.
410 Also, the behavior might break at any point in further development.
412 .U2 "Hardcopy terminal support
413 .P
414 More of a funny anecdote is the remaining of a check for printing to a
415 hardcopy terminal until Spring 2012, when I finally removed it.
416 I surely would be very happy to see such a terminal in action, maybe
417 actually being able to work on it, but I fear my chances are null.
418 .P
419 The check only prevented a pager to be placed between the outputting
420 program (\c
421 .Pn mhl )
422 and the terminal. This could have been ensured with
423 the
424 .Sw \-nomoreproc
425 at the command line statically, too.
427 .U2 "Removed support for header fields
428 .P
429 The `Encrypted' header had been introduced by RFC\^822, but already
430 marked legacy in RFC 2822. It was superseded by FIXME.
431 Mmh does no more support this header.
432 .P
433 Native support for `Face' headers
434 had been removed, as well.
435 The feature is similar to the `X-Face' header in its intent,
436 but takes a different approach to store the image.
437 Instead of encoding the image data directly into the header,
438 the the header contains the hostname and UDP port where the image
439 date could be retrieved.
440 Neither `X-Face' nor the here described `Face' system
441 \**
442 .FS
443 There is also a newer but different system, invented 2005,
444 using `Face' headers.
445 It is the successor of `X-Face' providing colored PNG images.
446 .FE
447 became well used in the large scale.
448 It's still possible to use a Face systems,
449 although mmh does not provide support for any of the different systems
450 anymore. It's fairly easy to write a small shell script to
451 extract the embedded or fetch the external Face data and display the image.
452 Own Face headers can be added into the draft template files.
453 .P
454 `Content-MD5' headers were introduced by RFC\^1864. They provide only
455 a verification of data corruption during the transfer. By no means can
456 they ensure verbatim end-to-end delivery of the contents. This is clearly
457 stated in the RFC. The proper approach to provide verificationability
458 of content in an end-to-end relationship is the use of digital cryptography
459 (RFCs FIXME). On the other hand, transfer protocols should ensure the
460 integrity of the transmission. In combinations these two approaches
461 make the `Content-MD5' header field useless. In consequence, I removed
462 the support for it. By this removal, MD5 computation is not needed
463 anywhere in mmh. Hence, over 500 lines of code were removed by this one
464 change. Even if the `Content-MD5' header field is useful sometimes,
465 I value its usefulnes less than the improvement in maintainability, caused
466 by the removal.
468 .U2 "Prompter's Control Keys
469 .P
470 The program
471 .Pn prompter
472 queries the user to fill in a message form. When used by
473 .Pn comp
474 as:
475 .DS
476 comp \-editor prompter
477 .DE
478 the resulting behavior is similar to
479 .Pn mailx .
480 Apparently,
481 .Pn prompter
482 hadn't been touched lately. Otherwise it's hardly explainable why it
483 still offered the switches
484 .Sn \-erase \fUchr\fP
485 and
486 .Sn \-kill \fUchr\fP
487 to name the characters for command line editing.
488 The times when this had been necessary are long time gone.
489 Today these things work out-of-the-box, and if not, are configured
490 with the standard tool
491 .Pn stty .
493 .U2 "Vfork and Retry Loops
494 .P
495 MH creates many processes, which is a consequence of the tool chest approach.
496 In earlier times
497 .Fu fork()
498 had been an expensive system call, as the process's whole image needed
499 to be duplicated. One common case is replacing the image with
500 .Fu exec()
501 right after having forked the child process.
502 To speed up this case, the
503 .Fu vfork()
504 system call was invented at Berkeley. It completely omits copying the
505 image. If the image gets replaced right afterwards then unnecessary
506 work is omited. On old systems this results in large speed ups.
507 MH uses
508 .Fu vfork()
509 whenever possible.
510 .P
511 Memory management units that support copy-on-write semantics make
512 .Fu fork()
513 almost as fast as
514 .Fu vfork()
515 in the cases when they can be exchanged.
516 With
517 .Fu vfork()
518 being more error-prone and hardly faster, it's preferable to simply
519 use
520 .Fu fork()
521 instead.
522 .P
523 Related to the costs of
524 .Fu fork()
525 is the probability of its success.
526 Today on modern systems, the system call will succeed almost always.
527 In the Eighties on heavy loaded systems, as they were common at
528 universities, this had been different. Thus, many of the
529 .Fu fork()
530 calls were wrapped into loops to retry to fork several times in
531 short intervals, in case of previous failure.
532 In mmh, the program aborts at once if the fork failed.
533 The user can reexecute the command then. This is expected to be a
534 very rare case on modern systems, especially personal ones, which are
535 common today.
538 .H2 "Attachments
539 .P
540 MIME
543 .H2 "Digital Cryptography
544 .P
545 Signing and encryption.
548 .H2 "Good Defaults
549 .P
550 foo
555 .H1 "Code style
556 .P
557 foo
560 .H2 "Standard Code
561 .P
562 POSIX
565 .H2 "Separation
567 .U2 "MH Directory Split
568 .P
569 In MH and nmh, a personal setup had consisted of two parts:
570 The MH profile, named
571 .Fn \&.mh_profile
572 and being located directly in the user's home directory.
573 And the MH directory, where all his mail messages and also his personal
574 forms, scan formats, other configuration files are stored. The location
575 of this directory could be user-chosen. The default was to name it
576 .Fn Mail
577 and have it directly in the home directory.
578 .P
579 I've never liked the data storage and the configuration to be intermixed.
580 They are different kinds of data. One part, are the messages,
581 which are the data to operate on. The other part, are the personal
582 configuration files, which are able to change the behavior of the operations.
583 The actual operations are defined in the profile, however.
584 .P
585 When storing data, one should try to group data by its type.
586 There's sense in the Unix file system hierarchy, where configuration
587 file are stored separate (\c
588 .Fn /etc )
589 to the programs (\c
590 .Fn /bin
591 and
592 .Fn /usr/bin )
593 to their sources (\c
594 .Fn /usr/src ).
595 Such separation eases the backup management, for instance.
596 .P
597 In mmh, I've reorganized the file locations.
598 Still there are two places:
599 There's the mail storage directory, which, like in MH, contains all the
600 messages, but, unlike in MH, nothing else.
601 Its location still is user-chosen, with the default name
602 .Fn Mail ,
603 in the user's home directory. This is much similar to the case in nmh.
604 The configuration files, however, are grouped together in the new directory
605 .Fn \&.mmh
606 in the user's home directory.
607 The user's profile now is a file, named
608 .Fn profile ,
609 in this mmh directory.
610 Consistently, the context file and all the personal forms, scan formats,
611 and the like, are also there.
612 .P
613 The naming changed with the relocation.
614 The directory where everything, except the profile, had been stored (\c
615 .Fn $HOME/Mail ),
616 used to be called \fIMH directory\fP. Now, this directory is called the
617 user's \fImail storage\fP. The name \fImmh directory\fP is now given to
618 the new directory
619 (\c
620 .Fn $HOME/.mmh ),
621 containing all the personal configuration files.
622 .P
623 The separation of the files by type of content is logical and convenient.
624 There are no functional differences as any possible setup known to me
625 can be implemented with both approaches, although likely a bit easier
626 with the new approach. The main goal of the change had been to provide
627 sensible storage locations for any type of personal mmh file.
628 .P
629 In order for one user to have multiple MH setups, he can use the
630 environment variable
631 .Ev MH
632 the point to a different profile file.
633 The MH directory (mail storage plus personal configuration files) is
634 defined by the
635 .Pe Path
636 profile entry.
637 The context file could be defined by the
638 .Pe context
639 profile entry or by the
640 .Ev MHCONTEXT
641 environment variable.
642 The latter is useful to have a distinct context (e.g. current folders)
643 in each terminal window, for instance.
644 In mmh, there are three environment variables now.
645 .Ev MMH
646 may be used to change the location of the mmh directory.
647 .Ev MMHP
648 and
649 .Ev MMHC
650 change the profile and context files, respectively.
651 Besides providing a more consistent feel (which simply is the result
652 of being designed anew), the set of personal configuration files can
653 be chosen independently from the profile (including mail storage location)
654 and context, now. Being it relevant for practical use or not, it
655 de-facto is an improvement. However, the main achievement is the
656 split between mail storage and personal configuration files.
659 .H2 "Modularization
660 .P
661 whatnowproc
662 .P
663 The \fIMH library\fP
664 .Fn libmh.a
665 collects a bunch of standard functions that many of the MH tools need,
666 like reading the profile or context files.
667 This doesn't hurt the separation.
670 .H2 "Style
671 .P
672 Code layout, goto, ...
677 .H1 "Concept Exploitation/Homogeniety
680 .H2 "Draft Folder
681 .P
682 Historically, MH provided exactly one draft message, named
683 .Fn draft
684 and
685 being located in the MH directory. When starting to compose another message
686 before the former one was sent, the user had been questioned whether to use,
687 refile or replace the old draft. Working on multiple drafts at the same time
688 was impossible. One could only work on them in alteration by refiling the
689 previous one to some directory and fetching some other one for reediting.
690 This manual draft management needed to be done each time the user wanted
691 to switch between editing one draft to editing another.
692 .P
693 To allow true parallel editing of drafts, in a straight forward way, the
694 draft folder facility exists. It had been introduced already in July 1984
695 by Marshall T. Rose. The facility was deactivated by default.
696 Even in nmh, the draft folder facility remained deactivated by default.
697 At least, Richard Coleman added the man page
698 .Mp mh-draft(5)
699 to document
700 the feature well.
701 .P
702 The only advantage of not using the draft folder facility is the static
703 name of the draft file. This could be an issue for MH frontends like mh-e.
704 But as they likely want to provide working on multiple drafts in parallel,
705 the issue is only concerning compatibility. The aim of nmh to stay compatible
706 prevented the default activation of the draft folder facility.
707 .P
708 On the other hand, a draft folder is the much more natural concept than
709 a draft message. MH's mail storage consists of folders and messages,
710 the messages named with ascending numbers. A draft message breaks with this
711 concept by introducing a message in a file named
712 .Fn draft .
713 This draft
714 message is special. It can not be simply listed with the available tools,
715 but instead requires special switches. I.e. corner-cases were
716 introduced. A draft folder, in contrast, does not introduce such
717 corner-cases. The available tools can operate on the messages within that
718 folder like on any messages within any mail folders. The only difference
719 is the fact that the default folder for
720 .Pn send
721 is the draft folder,
722 instead of the current folder, like for all other tools.
723 .P
724 The trivial part of the change was activating the draft folder facility
725 by default and setting a default name for this folder. Obviously, I chose
726 the name
727 .Fn +drafts .
728 This made the
729 .Sw \-draftfolder
730 and
731 .Sw \-draftmessage
732 switches useless, and I could remove them.
733 The more difficult but also the part that showed the real improvement,
734 was updating the tools to the new concept.
735 .Sw \-draft
736 switches could
737 be dropped, as operating on a draft message became indistinguishable to
738 operating on any other message for the tools.
739 .Pn comp
740 still has its
741 .Sw \-use
742 switch for switching between its two modes: (1) Compose a new
743 draft, possibly by taking some existing message as a form. (2) Modify
744 an existing draft. In either case, the behavior of
745 .Pn comp is
746 deterministic. There is no more need to query the user. I consider this
747 a major improvement. By making
748 .Pn send
749 simply operate on the current
750 message in the draft folder by default, with message and folder both
751 overridable by specifying them on the command line, it is now possible
752 to send a draft anywhere within the storage by simply specifying its folder
753 and name.
754 .P
755 All theses changes converted special cases to regular cases, thus
756 simplifying the tools and increasing the flexibility.
759 .H2 "Trash Folder
760 .P
761 Similar to the situation for drafts is the situation for removed messages.
762 Historically, a message was deleted by renaming. A specific
763 \fIbackup prefix\fP, often comma (\c
764 .Fn , )
765 or hash (\c
766 .Fn # ),
767 being prepended to the file name. Thus, MH wouldn't recognize the file
768 as a message anymore, as only files whose name consists of digits only
769 are treated as messages. The removed messages remained as files in the
770 same directory and needed some maintenance job to truly delete them after
771 some grace time. Usually, by running a command similar to
772 .DS
773 find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
774 .DE
775 in a cron job. Within the grace time interval
776 the original message could be restored by stripping the
777 the backup prefix from the file name. If however, the last message of
778 a folder is been removed \(en say message
779 .Fn 6
780 becomes file
781 .Fn ,6
782 \(en and a new message enters the same folder, thus the same
783 numbered being given again \(en in our case
784 .Fn 6
785 \(en, if that one
786 is removed too, then the backup of the former message gets overwritten.
787 Thus, the ability to restore removed messages does not only depend on
788 the ``sweeping cron job'' but also on the removing of further messages.
789 This is undesirable, because the real mechanism is hidden from the user
790 and the consequences of further removals are not always obvious.
791 Further more, the backup files are scattered within the whole mail
792 storage, instead of being collected at one place.
793 .P
794 To improve the situation, the profile entry
795 .Pe rmmproc
796 (previously named
797 .Pe Delete-Prog )
798 was introduced, very early.
799 It could be set to any command, which would care for the mail removal
800 instead of taking the default action, described above.
801 Refiling the to-be-removed files to some garbage folder was a common
802 example. Nmh's man page
803 .Mp rmm(1)
804 proposes
805 .Cl "refile +d
806 to move messages to the garbage folder and
807 .Cl "rm `mhpath +d all`
808 the empty the garbage folder.
809 Managing the message removal this way is a sane approach. It keeps
810 the removed messages in one place, makes it easy to remove the backup
811 files, and, most important, enables the user to use the tools of MH
812 itself to operate on the removed messages. One can
813 .Pn scan
814 them,
815 .Pn show
816 them, and restore them with
817 .Pn refile .
818 There's no more
819 need to use
820 .Pn mhpath
821 to switch over from MH tools to Unix tools \(en MH can do it all itself.
822 .P
823 This approach matches perfect with the concepts of MH, thus making
824 it powerful. Hence, I made it the default. And even more, I also
825 removed the old backup prefix approach, as it is clearly less powerful.
826 Keeping unused alternative in the code is a bad choice as they likely
827 gather bugs, by not being constantly tested. Also, the increased code
828 size and more conditions crease the maintenance costs. By strictly
829 converting to the trash folder approach, I simplified the code base.
830 .Pn rmm
831 calls
832 .Pn refile
833 internally to move the to-be-removed
834 message to the trash folder (\c
835 .Fn +trash
836 by default). Messages
837 there can be operated on like on any other message in the storage.
838 The sweep clean, one can use
839 .Cl "rmm \-unlink +trash a" ,
840 where the
841 .Sw \-unlink
842 switch causes the files to be truly unliked instead
843 of moved to the trash folder.
846 .H2 "Path Notations
847 .P
848 foo
851 .H2 "MIME Integration
852 .P
853 user-visible access to whole messages and MIME parts are inherently
854 different
857 .H2 "Of One Cast
858 .P