docs/master
view ch03.roff @ 72:bae9273b5802
Wrote about configure options (not finished yet).
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Sun, 03 Jun 2012 22:13:53 +0200 |
| parents | f80ced4e749b |
| children | cefaa856d431 |
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 4c1efddfd499300c7e74263e57d8aa137e84c853
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
386 Choice is a double-edged sword.
387 It allows customization and thus better suiting solutions,
388 but that comes with costs.
389 First, there is the cost of code complexity to have choice.
390 Second, there is the cost of less tested setups, because there are
391 more possible setups and especially corner-cases.
392 Third, there is the cost of choice itself.
393 The code complexity affects the developers.
394 Less tested code affects both, users and developers.
395 The problem of choice affects the users, for once simply by having to
396 choose but also by complexer interfaces that require more documentation.
397 Whenever options add little advantages, they should be considered for
398 removal.
399 .P
400 I have reduced the number of project-specific configure options from
401 fifteen to three.
402 .BU
403 With the removal of the mail transfer facilities five option vanished:
404 .IP \f(CW--with-mts=[smtp|sendmail]\fP
405 Specified the default mail transport service, which now is sendmail always.
406 .IP \f(CW--with-smtpservers=[server1...]\fP
407 Specified the default SMTP servers for the smtp mail transfer service.
408 .Ci 128545e06224233b7e91fc4c83f8830252fe16c9
409 .IP \f(CW--with-cyrus-sasl\fP
410 Enabled SASL support for mail transfer.
411 .IP \f(CW--with-tls\fP
412 Enabled TLS support for mail transfer.
413 .IP \f(CW--enable-pop\fP
414 Enabled the message retrieval facility.
415 .BU
416 --with-ndbm=ARG use -lARG to link with ndbm
417 --with-ndbmheader=ARG #include <ARG> to use ndbm
419 .BU
420 The default backup prefix, i.e. the string that was prepended to message
421 filenames to tag them as deleted, had been the comma `\f(CW,\fP'.
422 There was a configure option to change the default to the hash symbol
423 `\f(CW#\fP':
424 .CW --with-hash-backup .
425 The implication of the hash symbol is that it introduces a comment
426 in the Unix shell.
427 Thus, the command line
428 .Cl "rm #13 #15
429 calls
430 .Pn rm
431 without arguments because the first hash symbol starts the comment
432 that reaches until the end of the line.
433 To delete the backup files,
434 .Cl "rm ./#13 ./#15"
435 needs to be used.
436 .\" XXX check historical background
437 Besides this effect, the choice was personal preference.
438 I removed the configure option but added the profile entry
439 .Pe backup-prefix ,
440 which allows to specify an arbitrary string as backup prefix.
441 .Ci 6c40d481d661d532dd527eaf34cebb6d3f8ed086
442 This did not remove the choice but moved it to a location where
443 it suited better.
444 Profile entries are the common method to change mmh's behavior.
445 The name of the
446 .Fn .mh-sequences ,
447 for instance, is specified there, too.
448 Moving the specification of the backup prefix there, appears to be right.
449 Eventually, the new trash folder obsoleted the concept of the
450 backup prefix completely.
451 (Well, there still are corner-cases to remove until the backup
452 prefix can be layed to rest, eventually.)
453 .\" FIXME: Do this work in the code!
456 .P
457 --with-editor=EDITOR specify the default editor
458 --with-pager=PAGER specify the default pager
459 .Ci 5d43a99db70c12a673028c7758c20cbe3e13ef5f
461 .P
462 --disable-mhe disable mhe support
463 .Ci a7ce7b4a580d77b6c2c4d980812beb589aa4c643
465 .P
466 --enable-masquerade='draft_from mmailid username_extension' enable up to 3 types of address masquerading
467 --with-locking=[dot|fcntl|flock|lockf] specify the file locking method
468 --disable-locale turn off locale features
473 .H2 "Removal of switches
474 .P
479 .H1 "Moderizing
482 .H2 "Removal of Code Relicts
483 .P
484 The code base of mmh originates from the late Seventies,
485 had been extensively
486 worked on in the mid Eighties, and had been partly reorganized and extended
487 in the Nineties. Relicts of all those times had gathered in the code base.
488 My goal was to remove any ancient code parts. One part of the task was
489 converting obsolete code constructs to standard constructs, the other part
490 was dropping obsolete functions.
491 .P
492 As I'm not even thirty years old and have no more than seven years of
493 Unix experience, I needed to learn about the history in retrospective.
494 Older people likely have used those ancient constructs themselves
495 and have suffered from their incompatibilities and have longed for
496 standardization. Unfortunately, I have only read that others had done so.
497 This put me in a much more difficult positions when working on the old
498 code. I needed to recherche what other would have known by heart from
499 experience. All my programming experience comes from a time past ANSI C
500 and past POSIX. Although I knew about the times before, I took the
501 current state implicitly for granted most of the time.
502 .P
503 Being aware of
504 these facts, I rather let people with more historic experience solve the
505 task of converting the ancient code constructs to standardized ones.
506 Luckily, Lyndon Nerenberg focused on this task at the nmh project.
507 He converted large parts of the code to POSIX constructs, removing
508 the conditionals compilation for now standardized features.
509 I'm thankful for this task being solved. I only pulled the changes into
510 mmh.
511 .P
512 The other task \(en dropping ancient functionality to remove old code \(en
513 I did myself, though. My position to strip mmh to the bare minimum of
514 frequently used features is much more revolutional than the nmh community
515 likes it. Without the need to justify my decisions, I was able to quickly
516 remove functionality I considered ancient.
517 The need to discuss my decisions with
518 peers likely would have slowed this process down. Of course, I researched
519 if a particular feature really should be dropped. Having not had any
520 contact to this feature within my computer life was a first indicator to
521 drop it, but I also asked others and searched the literature for modern
522 usage of the feature. If it appeared to be truly ancient, I dropped it.
523 The reason for dropping is always part of the commit message in the
524 version control system. Thus, it is easy for others to check their
525 view on the topic with mine and possibly to argue for reinclusion.
527 .U2 "MMDF maildrop support
528 .P
529 I did drop any support for the MMDF maildrop format. This type of format
530 is conceptionally similar to the mbox format, but uses four bytes with
531 value 1 (\fL^A^A^A^A\fP) as message delimiter,
532 instead of the string ``\fLFrom\ \fP''.
533 Due to the similarity and mbox being the de-facto standard maildrop
534 format on Unix, but also due to the larger influence of Sendmail than MMDF,
535 the MMDF maildrop format had vanished.
536 .P
537 The simplifications within the code were only moderate. Switches could
538 be removed from tools like
539 .L packf ,
540 which generate packed mailboxes. Only one packed mailbox format remained:
541 mbox.
542 The most important changes affect the equally named mail parsing routine in
543 .L sbr/m_getfld.c .
544 The direct MMDF code had been removed, but as now only one packed mailbox
545 format is left, code structure simplifications are likely possible.
546 The reason why they are still outstanding is the heavily optimized code
547 of
548 .Fu m_getfld() .
549 Changes beyond a small local scope \(en
550 which restructuring in its core is \(en cause a high risk of damaging
551 the intricate workings of the optimized code. This problem is know
552 to the developers of nmh, too. They also avoid touching this minefield
553 if possible.
555 .U2 "UUCP Bang Paths
556 .P
557 More questionably than the former topic is the removal of support for the
558 UUCP bang path address style. However, the user may translate the bang
559 paths on retrieval to Internet addresses and the other way on posting
560 messages. The former can be done my an MDA like procmail; the latter
561 by a sendmail wrapper. This would ensure that any address handling would
562 work as expected. However, it might just work well without any
563 such modifications, as mmh does not touch addresses much, in general.
564 But I can't ensure as I have never used an environment with bang paths.
565 Also, the behavior might break at any point in further development.
567 .U2 "Hardcopy terminal support
568 .P
569 More of a funny anecdote is the remaining of a check for printing to a
570 hardcopy terminal until Spring 2012, when I finally removed it.
571 I surely would be very happy to see such a terminal in action, maybe
572 actually being able to work on it, but I fear my chances are null.
573 .P
574 The check only prevented a pager to be placed between the outputting
575 program (\c
576 .Pn mhl )
577 and the terminal. This could have been ensured with
578 the
579 .Sw \-nomoreproc
580 at the command line statically, too.
582 .U2 "Removed support for header fields
583 .P
584 The `Encrypted' header had been introduced by RFC\^822, but already
585 marked legacy in RFC 2822. It was superseded by FIXME.
586 Mmh does no more support this header.
587 .P
588 Native support for `Face' headers
589 had been removed, as well.
590 The feature is similar to the `X-Face' header in its intent,
591 but takes a different approach to store the image.
592 Instead of encoding the image data directly into the header,
593 the the header contains the hostname and UDP port where the image
594 date could be retrieved.
595 Neither `X-Face' nor the here described `Face' system
596 \**
597 .FS
598 There is also a newer but different system, invented 2005,
599 using `Face' headers.
600 It is the successor of `X-Face' providing colored PNG images.
601 .FE
602 became well used in the large scale.
603 It's still possible to use a Face systems,
604 although mmh does not provide support for any of the different systems
605 anymore. It's fairly easy to write a small shell script to
606 extract the embedded or fetch the external Face data and display the image.
607 Own Face headers can be added into the draft template files.
608 .P
609 `Content-MD5' headers were introduced by RFC\^1864. They provide only
610 a verification of data corruption during the transfer. By no means can
611 they ensure verbatim end-to-end delivery of the contents. This is clearly
612 stated in the RFC. The proper approach to provide verificationability
613 of content in an end-to-end relationship is the use of digital cryptography
614 (RFCs FIXME). On the other hand, transfer protocols should ensure the
615 integrity of the transmission. In combinations these two approaches
616 make the `Content-MD5' header field useless. In consequence, I removed
617 the support for it. By this removal, MD5 computation is not needed
618 anywhere in mmh. Hence, over 500 lines of code were removed by this one
619 change. Even if the `Content-MD5' header field is useful sometimes,
620 I value its usefulnes less than the improvement in maintainability, caused
621 by the removal.
623 .U2 "Prompter's Control Keys
624 .P
625 The program
626 .Pn prompter
627 queries the user to fill in a message form. When used by
628 .Pn comp
629 as:
630 .DS
631 comp \-editor prompter
632 .DE
633 the resulting behavior is similar to
634 .Pn mailx .
635 Apparently,
636 .Pn prompter
637 hadn't been touched lately. Otherwise it's hardly explainable why it
638 still offered the switches
639 .Sn \-erase \fUchr\fP
640 and
641 .Sn \-kill \fUchr\fP
642 to name the characters for command line editing.
643 The times when this had been necessary are long time gone.
644 Today these things work out-of-the-box, and if not, are configured
645 with the standard tool
646 .Pn stty .
648 .U2 "Vfork and Retry Loops
649 .P
650 MH creates many processes, which is a consequence of the tool chest approach.
651 In earlier times
652 .Fu fork()
653 had been an expensive system call, as the process's whole image needed
654 to be duplicated. One common case is replacing the image with
655 .Fu exec()
656 right after having forked the child process.
657 To speed up this case, the
658 .Fu vfork()
659 system call was invented at Berkeley. It completely omits copying the
660 image. If the image gets replaced right afterwards then unnecessary
661 work is omited. On old systems this results in large speed ups.
662 MH uses
663 .Fu vfork()
664 whenever possible.
665 .P
666 Memory management units that support copy-on-write semantics make
667 .Fu fork()
668 almost as fast as
669 .Fu vfork()
670 in the cases when they can be exchanged.
671 With
672 .Fu vfork()
673 being more error-prone and hardly faster, it's preferable to simply
674 use
675 .Fu fork()
676 instead.
677 .P
678 Related to the costs of
679 .Fu fork()
680 is the probability of its success.
681 Today on modern systems, the system call will succeed almost always.
682 In the Eighties on heavy loaded systems, as they were common at
683 universities, this had been different. Thus, many of the
684 .Fu fork()
685 calls were wrapped into loops to retry to fork several times in
686 short intervals, in case of previous failure.
687 In mmh, the program aborts at once if the fork failed.
688 The user can reexecute the command then. This is expected to be a
689 very rare case on modern systems, especially personal ones, which are
690 common today.
693 .H2 "Attachments
694 .P
695 MIME
698 .H2 "Digital Cryptography
699 .P
700 Signing and encryption.
703 .H2 "Good Defaults
704 .P
705 foo
710 .H1 "Code style
711 .P
712 foo
715 .H2 "Standard Code
716 .P
717 POSIX
720 .H2 "Separation
722 .U2 "MH Directory Split
723 .P
724 In MH and nmh, a personal setup had consisted of two parts:
725 The MH profile, named
726 .Fn \&.mh_profile
727 and being located directly in the user's home directory.
728 And the MH directory, where all his mail messages and also his personal
729 forms, scan formats, other configuration files are stored. The location
730 of this directory could be user-chosen. The default was to name it
731 .Fn Mail
732 and have it directly in the home directory.
733 .P
734 I've never liked the data storage and the configuration to be intermixed.
735 They are different kinds of data. One part, are the messages,
736 which are the data to operate on. The other part, are the personal
737 configuration files, which are able to change the behavior of the operations.
738 The actual operations are defined in the profile, however.
739 .P
740 When storing data, one should try to group data by its type.
741 There's sense in the Unix file system hierarchy, where configuration
742 file are stored separate (\c
743 .Fn /etc )
744 to the programs (\c
745 .Fn /bin
746 and
747 .Fn /usr/bin )
748 to their sources (\c
749 .Fn /usr/src ).
750 Such separation eases the backup management, for instance.
751 .P
752 In mmh, I've reorganized the file locations.
753 Still there are two places:
754 There's the mail storage directory, which, like in MH, contains all the
755 messages, but, unlike in MH, nothing else.
756 Its location still is user-chosen, with the default name
757 .Fn Mail ,
758 in the user's home directory. This is much similar to the case in nmh.
759 The configuration files, however, are grouped together in the new directory
760 .Fn \&.mmh
761 in the user's home directory.
762 The user's profile now is a file, named
763 .Fn profile ,
764 in this mmh directory.
765 Consistently, the context file and all the personal forms, scan formats,
766 and the like, are also there.
767 .P
768 The naming changed with the relocation.
769 The directory where everything, except the profile, had been stored (\c
770 .Fn $HOME/Mail ),
771 used to be called \fIMH directory\fP. Now, this directory is called the
772 user's \fImail storage\fP. The name \fImmh directory\fP is now given to
773 the new directory
774 (\c
775 .Fn $HOME/.mmh ),
776 containing all the personal configuration files.
777 .P
778 The separation of the files by type of content is logical and convenient.
779 There are no functional differences as any possible setup known to me
780 can be implemented with both approaches, although likely a bit easier
781 with the new approach. The main goal of the change had been to provide
782 sensible storage locations for any type of personal mmh file.
783 .P
784 In order for one user to have multiple MH setups, he can use the
785 environment variable
786 .Ev MH
787 the point to a different profile file.
788 The MH directory (mail storage plus personal configuration files) is
789 defined by the
790 .Pe Path
791 profile entry.
792 The context file could be defined by the
793 .Pe context
794 profile entry or by the
795 .Ev MHCONTEXT
796 environment variable.
797 The latter is useful to have a distinct context (e.g. current folders)
798 in each terminal window, for instance.
799 In mmh, there are three environment variables now.
800 .Ev MMH
801 may be used to change the location of the mmh directory.
802 .Ev MMHP
803 and
804 .Ev MMHC
805 change the profile and context files, respectively.
806 Besides providing a more consistent feel (which simply is the result
807 of being designed anew), the set of personal configuration files can
808 be chosen independently from the profile (including mail storage location)
809 and context, now. Being it relevant for practical use or not, it
810 de-facto is an improvement. However, the main achievement is the
811 split between mail storage and personal configuration files.
814 .H2 "Modularization
815 .P
816 whatnowproc
817 .P
818 The \fIMH library\fP
819 .Fn libmh.a
820 collects a bunch of standard functions that many of the MH tools need,
821 like reading the profile or context files.
822 This doesn't hurt the separation.
825 .H2 "Style
826 .P
827 Code layout, goto, ...
832 .H1 "Concept Exploitation/Homogeniety
835 .H2 "Draft Folder
836 .P
837 Historically, MH provided exactly one draft message, named
838 .Fn draft
839 and
840 being located in the MH directory. When starting to compose another message
841 before the former one was sent, the user had been questioned whether to use,
842 refile or replace the old draft. Working on multiple drafts at the same time
843 was impossible. One could only work on them in alteration by refiling the
844 previous one to some directory and fetching some other one for reediting.
845 This manual draft management needed to be done each time the user wanted
846 to switch between editing one draft to editing another.
847 .P
848 To allow true parallel editing of drafts, in a straight forward way, the
849 draft folder facility exists. It had been introduced already in July 1984
850 by Marshall T. Rose. The facility was deactivated by default.
851 Even in nmh, the draft folder facility remained deactivated by default.
852 At least, Richard Coleman added the man page
853 .Mp mh-draft(5)
854 to document
855 the feature well.
856 .P
857 The only advantage of not using the draft folder facility is the static
858 name of the draft file. This could be an issue for MH frontends like mh-e.
859 But as they likely want to provide working on multiple drafts in parallel,
860 the issue is only concerning compatibility. The aim of nmh to stay compatible
861 prevented the default activation of the draft folder facility.
862 .P
863 On the other hand, a draft folder is the much more natural concept than
864 a draft message. MH's mail storage consists of folders and messages,
865 the messages named with ascending numbers. A draft message breaks with this
866 concept by introducing a message in a file named
867 .Fn draft .
868 This draft
869 message is special. It can not be simply listed with the available tools,
870 but instead requires special switches. I.e. corner-cases were
871 introduced. A draft folder, in contrast, does not introduce such
872 corner-cases. The available tools can operate on the messages within that
873 folder like on any messages within any mail folders. The only difference
874 is the fact that the default folder for
875 .Pn send
876 is the draft folder,
877 instead of the current folder, like for all other tools.
878 .P
879 The trivial part of the change was activating the draft folder facility
880 by default and setting a default name for this folder. Obviously, I chose
881 the name
882 .Fn +drafts .
883 This made the
884 .Sw \-draftfolder
885 and
886 .Sw \-draftmessage
887 switches useless, and I could remove them.
888 The more difficult but also the part that showed the real improvement,
889 was updating the tools to the new concept.
890 .Sw \-draft
891 switches could
892 be dropped, as operating on a draft message became indistinguishable to
893 operating on any other message for the tools.
894 .Pn comp
895 still has its
896 .Sw \-use
897 switch for switching between its two modes: (1) Compose a new
898 draft, possibly by taking some existing message as a form. (2) Modify
899 an existing draft. In either case, the behavior of
900 .Pn comp is
901 deterministic. There is no more need to query the user. I consider this
902 a major improvement. By making
903 .Pn send
904 simply operate on the current
905 message in the draft folder by default, with message and folder both
906 overridable by specifying them on the command line, it is now possible
907 to send a draft anywhere within the storage by simply specifying its folder
908 and name.
909 .P
910 All theses changes converted special cases to regular cases, thus
911 simplifying the tools and increasing the flexibility.
914 .H2 "Trash Folder
915 .P
916 Similar to the situation for drafts is the situation for removed messages.
917 Historically, a message was deleted by renaming. A specific
918 \fIbackup prefix\fP, often comma (\c
919 .Fn , )
920 or hash (\c
921 .Fn # ),
922 being prepended to the file name. Thus, MH wouldn't recognize the file
923 as a message anymore, as only files whose name consists of digits only
924 are treated as messages. The removed messages remained as files in the
925 same directory and needed some maintenance job to truly delete them after
926 some grace time. Usually, by running a command similar to
927 .DS
928 find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm
929 .DE
930 in a cron job. Within the grace time interval
931 the original message could be restored by stripping the
932 the backup prefix from the file name. If however, the last message of
933 a folder is been removed \(en say message
934 .Fn 6
935 becomes file
936 .Fn ,6
937 \(en and a new message enters the same folder, thus the same
938 numbered being given again \(en in our case
939 .Fn 6
940 \(en, if that one
941 is removed too, then the backup of the former message gets overwritten.
942 Thus, the ability to restore removed messages does not only depend on
943 the ``sweeping cron job'' but also on the removing of further messages.
944 This is undesirable, because the real mechanism is hidden from the user
945 and the consequences of further removals are not always obvious.
946 Further more, the backup files are scattered within the whole mail
947 storage, instead of being collected at one place.
948 .P
949 To improve the situation, the profile entry
950 .Pe rmmproc
951 (previously named
952 .Pe Delete-Prog )
953 was introduced, very early.
954 It could be set to any command, which would care for the mail removal
955 instead of taking the default action, described above.
956 Refiling the to-be-removed files to some garbage folder was a common
957 example. Nmh's man page
958 .Mp rmm(1)
959 proposes
960 .Cl "refile +d
961 to move messages to the garbage folder and
962 .Cl "rm `mhpath +d all`
963 the empty the garbage folder.
964 Managing the message removal this way is a sane approach. It keeps
965 the removed messages in one place, makes it easy to remove the backup
966 files, and, most important, enables the user to use the tools of MH
967 itself to operate on the removed messages. One can
968 .Pn scan
969 them,
970 .Pn show
971 them, and restore them with
972 .Pn refile .
973 There's no more
974 need to use
975 .Pn mhpath
976 to switch over from MH tools to Unix tools \(en MH can do it all itself.
977 .P
978 This approach matches perfect with the concepts of MH, thus making
979 it powerful. Hence, I made it the default. And even more, I also
980 removed the old backup prefix approach, as it is clearly less powerful.
981 Keeping unused alternative in the code is a bad choice as they likely
982 gather bugs, by not being constantly tested. Also, the increased code
983 size and more conditions crease the maintenance costs. By strictly
984 converting to the trash folder approach, I simplified the code base.
985 .Pn rmm
986 calls
987 .Pn refile
988 internally to move the to-be-removed
989 message to the trash folder (\c
990 .Fn +trash
991 by default). Messages
992 there can be operated on like on any other message in the storage.
993 The sweep clean, one can use
994 .Cl "rmm \-unlink +trash a" ,
995 where the
996 .Sw \-unlink
997 switch causes the files to be truly unliked instead
998 of moved to the trash folder.
1001 .H2 "Path Notations
1002 .P
1003 foo
1006 .H2 "MIME Integration
1007 .P
1008 user-visible access to whole messages and MIME parts are inherently
1009 different
1012 .H2 "Of One Cast
1013 .P