docs/master
view ch03.roff @ 70:d6840bfbe04c
style: Use .substring to print only a prefix of the commit hash.
I can decide later how long a prefix I like to print.
If your troff doesn't support .substring, the whole hash is printed.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Sat, 02 Jun 2012 12:39:23 +0200 |
| parents | 4c9f4d05d90e |
| children | bae9273b5802 |
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 \(en already in the first concept paper \(en
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, additional 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 which replaced the
308 .Cl "mhn \-show
309 call.
310 .P
311 From then on, two message display tools were part of nmh.
312 Because it should not require user actions to invoke the right tool
313 whether the message uses MIME or not,
314 .Pn show
315 was extended to automatically hand the job over to
316 .Pn mhshow
317 if displaying the message would be beyond
318 .Pn show 's
319 abilities.
320 For convenience,
321 .Pn show
322 would still display MIME messages if they contained only a single text
323 part.
324 In consequence, the user would invoke
325 .Pn show
326 (possibly through
327 .Pn next
328 or
329 .Pn prev )
330 and get the message printed with either
331 .Pn show
332 or
333 .Pn mhshow ,
334 whatever was more appropriate.
335 (There was also a switch for
336 .Pn show
337 to never invoke
338 .Pn mhshow .)
339 .P
340 Having two similar tools for essentially the same task is redundant.
341 Both programs needed to be developed syncronously as they were
342 used as a single tool by the user. Thus they needed to act in a
343 similar way to not distract the user.
344 .P
345 Today, non-MIME messages are rather seen to be a special case of
346 MIME messages, than MIME messages are seen to be an extension to
347 original mail.
348 As
349 .Pn mhshow
350 had already be able to display non-MIME messages, it was natural
351 to drop
352 .Pn show
353 in favor of using
354 .Pn mhshow
355 exclusively.
356 .Ci 4c1efdd
357 This decision follows the idea of orthogonal design.
358 .P
359 To allow this replacement,
360 .Pn mhshow
361 was reworked to behave more like
362 .Pn show
363 first.
364 Section XXX describes this rework from a different perspective.
365 Once the tools behaved similar, the replacing became a natural decision.
366 In mmh,
367 .Pn show
368 is the one single message display program again, but it handles
369 MIME messages as well as non-MIME messages.
370 There's only one program to maintain and users don't need to deal
371 with the existance of two display programs.
372 .P
373 Though, there's one reason why removing the old
374 .Pn show
375 hurts: It had been such a simple program.
376 Its lean elegance is missing to
377 .Pn mhshow ,
378 i.e. the new
379 .Pn show .
380 But there is no chance, because supporting MIME causes essentially
381 higher complexity.
384 .H2 "Removal of Configure Options
385 .P
388 .H2 "Removal of switches
389 .P
394 .H1 "Moderizing
397 .H2 "Removal of Code Relicts
398 .P
399 The code base of mmh originates from the late Seventies,
400 had been extensively
401 worked on in the mid Eighties, and had been partly reorganized and extended
402 in the Nineties. Relicts of all those times had gathered in the code base.
403 My goal was to remove any ancient code parts. One part of the task was
404 converting obsolete code constructs to standard constructs, the other part
405 was dropping obsolete functions.
406 .P
407 As I'm not even thirty years old and have no more than seven years of
408 Unix experience, I needed to learn about the history in retrospective.
409 Older people likely have used those ancient constructs themselves
410 and have suffered from their incompatibilities and have longed for
411 standardization. Unfortunately, I have only read that others had done so.
412 This put me in a much more difficult positions when working on the old
413 code. I needed to recherche what other would have known by heart from
414 experience. All my programming experience comes from a time past ANSI C
415 and past POSIX. Although I knew about the times before, I took the
416 current state implicitly for granted most of the time.
417 .P
418 Being aware of
419 these facts, I rather let people with more historic experience solve the
420 task of converting the ancient code constructs to standardized ones.
421 Luckily, Lyndon Nerenberg focused on this task at the nmh project.
422 He converted large parts of the code to POSIX constructs, removing
423 the conditionals compilation for now standardized features.
424 I'm thankful for this task being solved. I only pulled the changes into
425 mmh.
426 .P
427 The other task \(en dropping ancient functionality to remove old code \(en
428 I did myself, though. My position to strip mmh to the bare minimum of
429 frequently used features is much more revolutional than the nmh community
430 likes it. Without the need to justify my decisions, I was able to quickly
431 remove functionality I considered ancient.
432 The need to discuss my decisions with
433 peers likely would have slowed this process down. Of course, I researched
434 if a particular feature really should be dropped. Having not had any
435 contact to this feature within my computer life was a first indicator to
436 drop it, but I also asked others and searched the literature for modern
437 usage of the feature. If it appeared to be truly ancient, I dropped it.
438 The reason for dropping is always part of the commit message in the
439 version control system. Thus, it is easy for others to check their
440 view on the topic with mine and possibly to argue for reinclusion.
442 .U2 "MMDF maildrop support
443 .P
444 I did drop any support for the MMDF maildrop format. This type of format
445 is conceptionally similar to the mbox format, but uses four bytes with
446 value 1 (\fL^A^A^A^A\fP) as message delimiter,
447 instead of the string ``\fLFrom\ \fP''.
448 Due to the similarity and mbox being the de-facto standard maildrop
449 format on Unix, but also due to the larger influence of Sendmail than MMDF,
450 the MMDF maildrop format had vanished.
451 .P
452 The simplifications within the code were only moderate. Switches could
453 be removed from tools like
454 .L packf ,
455 which generate packed mailboxes. Only one packed mailbox format remained:
456 mbox.
457 The most important changes affect the equally named mail parsing routine in
458 .L sbr/m_getfld.c .
459 The direct MMDF code had been removed, but as now only one packed mailbox
460 format is left, code structure simplifications are likely possible.
461 The reason why they are still outstanding is the heavily optimized code
462 of
463 .Fu m_getfld() .
464 Changes beyond a small local scope \(en
465 which restructuring in its core is \(en cause a high risk of damaging
466 the intricate workings of the optimized code. This problem is know
467 to the developers of nmh, too. They also avoid touching this minefield
468 if possible.
470 .U2 "UUCP Bang Paths
471 .P
472 More questionably than the former topic is the removal of support for the
473 UUCP bang path address style. However, the user may translate the bang
474 paths on retrieval to Internet addresses and the other way on posting
475 messages. The former can be done my an MDA like procmail; the latter
476 by a sendmail wrapper. This would ensure that any address handling would
477 work as expected. However, it might just work well without any
478 such modifications, as mmh does not touch addresses much, in general.
479 But I can't ensure as I have never used an environment with bang paths.
480 Also, the behavior might break at any point in further development.
482 .U2 "Hardcopy terminal support
483 .P
484 More of a funny anecdote is the remaining of a check for printing to a
485 hardcopy terminal until Spring 2012, when I finally removed it.
486 I surely would be very happy to see such a terminal in action, maybe
487 actually being able to work on it, but I fear my chances are null.
488 .P
489 The check only prevented a pager to be placed between the outputting
490 program (\c
491 .Pn mhl )
492 and the terminal. This could have been ensured with
493 the
494 .Sw \-nomoreproc
495 at the command line statically, too.
497 .U2 "Removed support for header fields
498 .P
499 The `Encrypted' header had been introduced by RFC\^822, but already
500 marked legacy in RFC 2822. It was superseded by FIXME.
501 Mmh does no more support this header.
502 .P
503 Native support for `Face' headers
504 had been removed, as well.
505 The feature is similar to the `X-Face' header in its intent,
506 but takes a different approach to store the image.
507 Instead of encoding the image data directly into the header,
508 the the header contains the hostname and UDP port where the image
509 date could be retrieved.
510 Neither `X-Face' nor the here described `Face' system
511 \**
512 .FS
513 There is also a newer but different system, invented 2005,
514 using `Face' headers.
515 It is the successor of `X-Face' providing colored PNG images.
516 .FE
517 became well used in the large scale.
518 It's still possible to use a Face systems,
519 although mmh does not provide support for any of the different systems
520 anymore. It's fairly easy to write a small shell script to
521 extract the embedded or fetch the external Face data and display the image.
522 Own Face headers can be added into the draft template files.
523 .P
524 `Content-MD5' headers were introduced by RFC\^1864. They provide only
525 a verification of data corruption during the transfer. By no means can
526 they ensure verbatim end-to-end delivery of the contents. This is clearly
527 stated in the RFC. The proper approach to provide verificationability
528 of content in an end-to-end relationship is the use of digital cryptography
529 (RFCs FIXME). On the other hand, transfer protocols should ensure the
530 integrity of the transmission. In combinations these two approaches
531 make the `Content-MD5' header field useless. In consequence, I removed
532 the support for it. By this removal, MD5 computation is not needed
533 anywhere in mmh. Hence, over 500 lines of code were removed by this one
534 change. Even if the `Content-MD5' header field is useful sometimes,
535 I value its usefulnes less than the improvement in maintainability, caused
536 by the removal.
538 .U2 "Prompter's Control Keys
539 .P
540 The program
541 .Pn prompter
542 queries the user to fill in a message form. When used by
543 .Pn comp
544 as:
545 .DS
546 comp \-editor prompter
547 .DE
548 the resulting behavior is similar to
549 .Pn mailx .
550 Apparently,
551 .Pn prompter
552 hadn't been touched lately. Otherwise it's hardly explainable why it
553 still offered the switches
554 .Sn \-erase \fUchr\fP
555 and
556 .Sn \-kill \fUchr\fP
557 to name the characters for command line editing.
558 The times when this had been necessary are long time gone.
559 Today these things work out-of-the-box, and if not, are configured
560 with the standard tool
561 .Pn stty .
563 .U2 "Vfork and Retry Loops
564 .P
565 MH creates many processes, which is a consequence of the tool chest approach.
566 In earlier times
567 .Fu fork()
568 had been an expensive system call, as the process's whole image needed
569 to be duplicated. One common case is replacing the image with
570 .Fu exec()
571 right after having forked the child process.
572 To speed up this case, the
573 .Fu vfork()
574 system call was invented at Berkeley. It completely omits copying the
575 image. If the image gets replaced right afterwards then unnecessary
576 work is omited. On old systems this results in large speed ups.
577 MH uses
578 .Fu vfork()
579 whenever possible.
580 .P
581 Memory management units that support copy-on-write semantics make
582 .Fu fork()
583 almost as fast as
584 .Fu vfork()
585 in the cases when they can be exchanged.
586 With
587 .Fu vfork()
588 being more error-prone and hardly faster, it's preferable to simply
589 use
590 .Fu fork()
591 instead.
592 .P
593 Related to the costs of
594 .Fu fork()
595 is the probability of its success.
596 Today on modern systems, the system call will succeed almost always.
597 In the Eighties on heavy loaded systems, as they were common at
598 universities, this had been different. Thus, many of the
599 .Fu fork()
600 calls were wrapped into loops to retry to fork several times in
601 short intervals, in case of previous failure.
602 In mmh, the program aborts at once if the fork failed.
603 The user can reexecute the command then. This is expected to be a
604 very rare case on modern systems, especially personal ones, which are
605 common today.
608 .H2 "Attachments
609 .P
610 MIME
613 .H2 "Digital Cryptography
614 .P
615 Signing and encryption.
618 .H2 "Good Defaults
619 .P
620 foo
625 .H1 "Code style
626 .P
627 foo
630 .H2 "Standard Code
631 .P
632 POSIX
635 .H2 "Separation
637 .U2 "MH Directory Split
638 .P
639 In MH and nmh, a personal setup had consisted of two parts:
640 The MH profile, named
641 .Fn \&.mh_profile
642 and being located directly in the user's home directory.
643 And the MH directory, where all his mail messages and also his personal
644 forms, scan formats, other configuration files are stored. The location
645 of this directory could be user-chosen. The default was to name it
646 .Fn Mail
647 and have it directly in the home directory.
648 .P
649 I've never liked the data storage and the configuration to be intermixed.
650 They are different kinds of data. One part, are the messages,
651 which are the data to operate on. The other part, are the personal
652 configuration files, which are able to change the behavior of the operations.
653 The actual operations are defined in the profile, however.
654 .P
655 When storing data, one should try to group data by its type.
656 There's sense in the Unix file system hierarchy, where configuration
657 file are stored separate (\c
658 .Fn /etc )
659 to the programs (\c
660 .Fn /bin
661 and
662 .Fn /usr/bin )
663 to their sources (\c
664 .Fn /usr/src ).
665 Such separation eases the backup management, for instance.
666 .P
667 In mmh, I've reorganized the file locations.
668 Still there are two places:
669 There's the mail storage directory, which, like in MH, contains all the
670 messages, but, unlike in MH, nothing else.
671 Its location still is user-chosen, with the default name
672 .Fn Mail ,
673 in the user's home directory. This is much similar to the case in nmh.
674 The configuration files, however, are grouped together in the new directory
675 .Fn \&.mmh
676 in the user's home directory.
677 The user's profile now is a file, named
678 .Fn profile ,
679 in this mmh directory.
680 Consistently, the context file and all the personal forms, scan formats,
681 and the like, are also there.
682 .P
683 The naming changed with the relocation.
684 The directory where everything, except the profile, had been stored (\c
685 .Fn $HOME/Mail ),
686 used to be called \fIMH directory\fP. Now, this directory is called the
687 user's \fImail storage\fP. The name \fImmh directory\fP is now given to
688 the new directory
689 (\c
690 .Fn $HOME/.mmh ),
691 containing all the personal configuration files.
692 .P
693 The separation of the files by type of content is logical and convenient.
694 There are no functional differences as any possible setup known to me
695 can be implemented with both approaches, although likely a bit easier
696 with the new approach. The main goal of the change had been to provide
697 sensible storage locations for any type of personal mmh file.
698 .P
699 In order for one user to have multiple MH setups, he can use the
700 environment variable
701 .Ev MH
702 the point to a different profile file.
703 The MH directory (mail storage plus personal configuration files) is
704 defined by the
705 .Pe Path
706 profile entry.
707 The context file could be defined by the
708 .Pe context
709 profile entry or by the
710 .Ev MHCONTEXT
711 environment variable.
712 The latter is useful to have a distinct context (e.g. current folders)
713 in each terminal window, for instance.
714 In mmh, there are three environment variables now.
715 .Ev MMH
716 may be used to change the location of the mmh directory.
717 .Ev MMHP
718 and
719 .Ev MMHC
720 change the profile and context files, respectively.
721 Besides providing a more consistent feel (which simply is the result
722 of being designed anew), the set of personal configuration files can
723 be chosen independently from the profile (including mail storage location)
724 and context, now. Being it relevant for practical use or not, it
725 de-facto is an improvement. However, the main achievement is the
726 split between mail storage and personal configuration files.
729 .H2 "Modularization
730 .P
731 whatnowproc
732 .P
733 The \fIMH library\fP
734 .Fn libmh.a
735 collects a bunch of standard functions that many of the MH tools need,
736 like reading the profile or context files.
737 This doesn't hurt the separation.
740 .H2 "Style
741 .P
742 Code layout, goto, ...
747 .H1 "Concept Exploitation/Homogeniety
750 .H2 "Draft Folder
751 .P
752 Historically, MH provided exactly one draft message, named
753 .Fn draft
754 and
755 being located in the MH directory. When starting to compose another message
756 before the former one was sent, the user had been questioned whether to use,
757 refile or replace the old draft. Working on multiple drafts at the same time
758 was impossible. One could only work on them in alteration by refiling the
759 previous one to some directory and fetching some other one for reediting.
760 This manual draft management needed to be done each time the user wanted
761 to switch between editing one draft to editing another.
762 .P
763 To allow true parallel editing of drafts, in a straight forward way, the
764 draft folder facility exists. It had been introduced already in July 1984
765 by Marshall T. Rose. The facility was deactivated by default.
766 Even in nmh, the draft folder facility remained deactivated by default.
767 At least, Richard Coleman added the man page
768 .Mp mh-draft(5)
769 to document
770 the feature well.
771 .P
772 The only advantage of not using the draft folder facility is the static
773 name of the draft file. This could be an issue for MH frontends like mh-e.
774 But as they likely want to provide working on multiple drafts in parallel,
775 the issue is only concerning compatibility. The aim of nmh to stay compatible
776 prevented the default activation of the draft folder facility.
777 .P
778 On the other hand, a draft folder is the much more natural concept than
779 a draft message. MH's mail storage consists of folders and messages,
780 the messages named with ascending numbers. A draft message breaks with this
781 concept by introducing a message in a file named
782 .Fn draft .
783 This draft
784 message is special. It can not be simply listed with the available tools,
785 but instead requires special switches. I.e. corner-cases were
786 introduced. A draft folder, in contrast, does not introduce such
787 corner-cases. The available tools can operate on the messages within that
788 folder like on any messages within any mail folders. The only difference
789 is the fact that the default folder for
790 .Pn send
791 is the draft folder,
792 instead of the current folder, like for all other tools.
793 .P
794 The trivial part of the change was activating the draft folder facility
795 by default and setting a default name for this folder. Obviously, I chose
796 the name
797 .Fn +drafts .
798 This made the
799 .Sw \-draftfolder
800 and
801 .Sw \-draftmessage
802 switches useless, and I could remove them.
803 The more difficult but also the part that showed the real improvement,
804 was updating the tools to the new concept.
805 .Sw \-draft
806 switches could
807 be dropped, as operating on a draft message became indistinguishable to
808 operating on any other message for the tools.
809 .Pn comp
810 still has its
811 .Sw \-use
812 switch for switching between its two modes: (1) Compose a new
813 draft, possibly by taking some existing message as a form. (2) Modify
814 an existing draft. In either case, the behavior of
815 .Pn comp is
816 deterministic. There is no more need to query the user. I consider this
817 a major improvement. By making
818 .Pn send
819 simply operate on the current
820 message in the draft folder by default, with message and folder both
821 overridable by specifying them on the command line, it is now possible
822 to send a draft anywhere within the storage by simply specifying its folder
823 and name.
824 .P
825 All theses changes converted special cases to regular cases, thus
826 simplifying the tools and increasing the flexibility.
829 .H2 "Trash Folder
830 .P
831 Similar to the situation for drafts is the situation for removed messages.
832 Historically, a message was deleted by renaming. A specific
833 \fIbackup prefix\fP, often comma (\c
834 .Fn , )
835 or hash (\c
836 .Fn # ),
837 being prepended to the file name. Thus, MH wouldn't recognize the file
838 as a message anymore, as only files whose name consists of digits only
839 are treated as messages. The removed messages remained as files in the
840 same directory and needed some maintenance job to truly delete them after
841 some grace time. Usually, by running a command similar to
842 .DS
843 find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
844 .DE
845 in a cron job. Within the grace time interval
846 the original message could be restored by stripping the
847 the backup prefix from the file name. If however, the last message of
848 a folder is been removed \(en say message
849 .Fn 6
850 becomes file
851 .Fn ,6
852 \(en and a new message enters the same folder, thus the same
853 numbered being given again \(en in our case
854 .Fn 6
855 \(en, if that one
856 is removed too, then the backup of the former message gets overwritten.
857 Thus, the ability to restore removed messages does not only depend on
858 the ``sweeping cron job'' but also on the removing of further messages.
859 This is undesirable, because the real mechanism is hidden from the user
860 and the consequences of further removals are not always obvious.
861 Further more, the backup files are scattered within the whole mail
862 storage, instead of being collected at one place.
863 .P
864 To improve the situation, the profile entry
865 .Pe rmmproc
866 (previously named
867 .Pe Delete-Prog )
868 was introduced, very early.
869 It could be set to any command, which would care for the mail removal
870 instead of taking the default action, described above.
871 Refiling the to-be-removed files to some garbage folder was a common
872 example. Nmh's man page
873 .Mp rmm(1)
874 proposes
875 .Cl "refile +d
876 to move messages to the garbage folder and
877 .Cl "rm `mhpath +d all`
878 the empty the garbage folder.
879 Managing the message removal this way is a sane approach. It keeps
880 the removed messages in one place, makes it easy to remove the backup
881 files, and, most important, enables the user to use the tools of MH
882 itself to operate on the removed messages. One can
883 .Pn scan
884 them,
885 .Pn show
886 them, and restore them with
887 .Pn refile .
888 There's no more
889 need to use
890 .Pn mhpath
891 to switch over from MH tools to Unix tools \(en MH can do it all itself.
892 .P
893 This approach matches perfect with the concepts of MH, thus making
894 it powerful. Hence, I made it the default. And even more, I also
895 removed the old backup prefix approach, as it is clearly less powerful.
896 Keeping unused alternative in the code is a bad choice as they likely
897 gather bugs, by not being constantly tested. Also, the increased code
898 size and more conditions crease the maintenance costs. By strictly
899 converting to the trash folder approach, I simplified the code base.
900 .Pn rmm
901 calls
902 .Pn refile
903 internally to move the to-be-removed
904 message to the trash folder (\c
905 .Fn +trash
906 by default). Messages
907 there can be operated on like on any other message in the storage.
908 The sweep clean, one can use
909 .Cl "rmm \-unlink +trash a" ,
910 where the
911 .Sw \-unlink
912 switch causes the files to be truly unliked instead
913 of moved to the trash folder.
916 .H2 "Path Notations
917 .P
918 foo
921 .H2 "MIME Integration
922 .P
923 user-visible access to whole messages and MIME parts are inherently
924 different
927 .H2 "Of One Cast
928 .P