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