Mercurial > docs > master

comparison ch03.roff @ 58:814c33b96d89

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Restructured the content in ch03.
author markus schnalke <meillo@marmaro.de>
date Fri, 01 Jun 2012 12:33:49 +0200
parents 49cf68506b5d
children 6a92e0208de0
comparison
equal deleted inserted replaced
57:8776101db595 58:814c33b96d89
1 .H0 "Work Report 1 .H0 "Discussion
2 .P 2 .P
3 foo 3 This main chapter discusses the practical work done in the mmh project.
4 .P 4 It is structured along the goals to achieve. The concrete work done
5 bar 5 is described in the examples of how the general goals were achieved.
6 6
7 .H1 "Removal of Code Relicts 7
8
9
10 .H1 "Stream-lining
11
12
13 .H2 "Removal of non-MUA Tools
14 .P
15 MH had been considered an all-in-one system for mail handling.
16 The community around nmh has a similar understanding.
17 In fundamental difference, I believe that mmh should be a MUA but
18 nothing more. I believe that all-in-one mail systems are not the way
19 to go. There are excellent specialized MTAs, like Postfix;
20 there are specialized MDAs, like Procmail; there are specialized
21 MRAs, like Fetchmail. I believe it's best to use them instead of
22 providing the same function ourselves. Doing something well requires to
23 focus on this particular aspect or a small set of aspects. The more
24 it is possible to focus, the better the result in this particular
25 area will be. The limiting resource in Free Software community development
26 usually is human power. If the low development power is even parted
27 into multiple development areas, it will hardly be possible to
28 compete with the specialists in the various fields. This is even
29 increased, given the small community \(en developers and users \(en
30 that MH-based mail systems have. In consequence, I believe that the
31 available resources should be concentrated at the point where MH is
32 most unique. This is clearly the MUA part.
33 .P
34 Several of nmh's tools were removed from mmh because they didn't
35 match the main focus of adding to the MUA's task.
36 .P
37 .Pn conflict
38 was removed because it is a mail system maintenance tool.
39 Besides, it also checks the
40 .Fn /etc/passwd
41 and
42 .Fn /etc/group
43 files.
44 The tool might be useful, but it should not be shipped with mmh.
45 .P
46 .Pn rcvtty
47 was removed because its usecase of writing to the user's terminal
48 on receiving of mail is hardly wanted today. If users like to be
49 informed of new mail, then using the shell's
50 .Ev MAILPATH
51 variable or different (graphical) notifications are likely more
52 appealing. Writing directly to other terminals is hardly ever wanted
53 today. If though one wants to have it this way, the standard tool
54 .Pn write
55 can be used in a way similar to:
56 .DS
57 scan -file - | write `id -un`
58 .DE
59 .P
60 When the new attachment system was introduced,
61 .Pn viamail
62 was removed because then
63 .Pn forw
64 could cover the task itself.
65 The wrapper program
66 .Pn sendfiles
67 was rewritten as a shell script to use
68 .Pn forw .
69 .P
70 .Pn msgchk
71 was removed as it became hardly useful when POP support was removed.
72 It is questionable if
73 .Pn msgchk
74 provides more information than:
75 .DS
76 ls -l /var/mail/meillo
77 .DE
78 It does separate between old and new mail, but that's not very
79 useful and can be found out with
80 .Pn stat (1)
81 too. A very small shell script could care for the form of output.
82 As mmh's inc only incorporates mail from the user's local maildrop
83 and thus no long data transfers are involved,
84 there's no need to check for new mail before incorporating it.
85 .P
86 .Pn msh
87 was removed because the tool was in conflict with the original
88 philosophy of MH. It provided an interactive shell to access the
89 features of MH. One major feature of MH is being a tool chest.
90 .Pn msh
91 wouldn't be just another shell, tailored to the needs of mail
92 handling, but one large program to have the MH tools built in.
93 It's main use was for accessing Bulletin Boards, which have seized to
94 be popular. Removing
95 .Pn msh ,
96 together with the truly obsolete programs
97 .Pn vmh
98 and
99 .Pn wmh ,
100 saved more than 7\|000 lines of C code \(en a major achievement.
101
102 .U2 "Removal of the MTS
103 .P
104
105
106 .H2 "mhshow show Merge
107 .P
108 Since the very beginning, already in the first concept paper,
109 .Pn show
110 had been MH's mail display program.
111 .Pn show
112 found out which pathnames the relevant messages had and invoked
113 .Pn mhl
114 then to let it render the content.
115 With the advent of MIME, this approach wasn't sufficient anymore.
116 MIME messages can consist of multiple parts, some of which aren't
117 directly displayable, and text content can be encoded in
118 foreign charsets.
119 .Pn show 's
120 simple approach and
121 .Pn mhl 's
122 limited display facilities couldn't cope with the task any longer.
123 Instead of extending these tools, new ones were written from scratch
124 and then added to the MH tool chest. Doing so is encouraged by the
125 tool chest approach. The new tools could be added without interfering
126 with the existing ones. This is great. It allowed MH to be the
127 first MUA to implement MIME.
128 .P
129 The new MIME features were added in form of the single program
130 .Pn mhn .
131 The command
132 .DS
133 mhn \-show 42
134 .DE
135 would show the MIME message numbered 42.
136 With the 1.0 release of nmh in February 1999, Richard Coleman finished
137 the split of
138 .Pn mhn
139 into a set of specialized programs, which together covered the
140 aspects of MIME. One of these resulting tools was
141 .Pn mhshow .
142
143
144 .H2 "Removal of Configure Options
145 .P
146
147 .H2 "Removal of switches
148 .P
149
150
151
152
153 .H1 "Moderizing
154
155
156 .H2 "Removal of Code Relicts
8 .P 157 .P
9 The code base of mmh originates from the late Seventies, 158 The code base of mmh originates from the late Seventies,
10 had been extensively 159 had been extensively
11 worked on in the mid Eighties, and had been partly reorganized and extended 160 worked on in the mid Eighties, and had been partly reorganized and extended
12 in the Nineties. Relicts of all those times had gathered in the code base. 161 in the Nineties. Relicts of all those times had gathered in the code base.
213 The user can reexecute the command then. This is expected to be a 362 The user can reexecute the command then. This is expected to be a
214 very rare case on modern systems, especially personal ones, which are 363 very rare case on modern systems, especially personal ones, which are
215 common today. 364 common today.
216 365
217 366
218 .H1 "Removal of Tools 367 .H2 "Attachments
219 .P 368 .P
220 MH had been considered an all-in-one system for mail handling. 369 MIME
221 The community around nmh has a similar understanding. 370
222 In fundamental difference, I believe that mmh should be a MUA but 371
223 nothing more. I believe that all-in-one mail systems are not the way 372 .H2 "Digital Cryptography
224 to go. There are excellent specialized MTAs, like Postfix; 373 .P
225 there are specialized MDAs, like Procmail; there are specialized 374 Signing and encryption.
226 MRAs, like Fetchmail. I believe it's best to use them instead of 375
227 providing the same function ourselves. Doing something well requires to 376
228 focus on this particular aspect or a small set of aspects. The more 377 .H2 "Good Defaults
229 it is possible to focus, the better the result in this particular 378 .P
230 area will be. The limiting resource in Free Software community development 379 foo
231 usually is human power. If the low development power is even parted 380
232 into multiple development areas, it will hardly be possible to 381
233 compete with the specialists in the various fields. This is even 382
234 increased, given the small community \(en developers and users \(en 383
235 that MH-based mail systems have. In consequence, I believe that the 384 .H1 "Code style
236 available resources should be concentrated at the point where MH is 385 .P
237 most unique. This is clearly the MUA part. 386 foo
238 .P 387
239 Several of nmh's tools were removed from mmh because they didn't 388
240 match the main focus of adding to the MUA's task. 389 .H2 "Standard Code
241 .P 390 .P
242 .Pn conflict 391 POSIX
243 was removed because it is a mail system maintenance tool. 392
244 Besides, it also checks the 393
245 .Fn /etc/passwd 394 .H2 "Separation
395
396 .U2 "MH Directory Split
397 .P
398 In MH and nmh, a personal setup had consisted of two parts:
399 The MH profile, named
400 .Fn \&.mh_profile
401 and being located directly in the user's home directory.
402 And the MH directory, where all his mail messages and also his personal
403 forms, scan formats, other configuration files are stored. The location
404 of this directory could be user-chosen. The default was to name it
405 .Fn Mail
406 and have it directly in the home directory.
407 .P
408 I've never liked the data storage and the configuration to be intermixed.
409 They are different kinds of data. One part, are the messages,
410 which are the data to operate on. The other part, are the personal
411 configuration files, which are able to change the behavior of the operations.
412 The actual operations are defined in the profile, however.
413 .P
414 When storing data, one should try to group data by its type.
415 There's sense in the Unix file system hierarchy, where configuration
416 file are stored separate (\c
417 .Fn /etc )
418 to the programs (\c
419 .Fn /bin
246 and 420 and
247 .Fn /etc/group 421 .Fn /usr/bin )
248 files. 422 to their sources (\c
249 The tool might be useful, but it should not be shipped with mmh. 423 .Fn /usr/src ).
250 .P 424 Such separation eases the backup management, for instance.
251 .Pn rcvtty 425 .P
252 was removed because its usecase of writing to the user's terminal 426 In mmh, I've reorganized the file locations.
253 on receiving of mail is hardly wanted today. If users like to be 427 Still there are two places:
254 informed of new mail, then using the shell's 428 There's the mail storage directory, which, like in MH, contains all the
255 .Ev MAILPATH 429 messages, but, unlike in MH, nothing else.
256 variable or different (graphical) notifications are likely more 430 Its location still is user-chosen, with the default name
257 appealing. Writing directly to other terminals is hardly ever wanted 431 .Fn Mail ,
258 today. If though one wants to have it this way, the standard tool 432 in the user's home directory. This is much similar to the case in nmh.
259 .Pn write 433 The configuration files, however, are grouped together in the new directory
260 can be used in a way similar to: 434 .Fn \&.mmh
261 .DS 435 in the user's home directory.
262 scan -file - | write `id -un` 436 The user's profile now is a file, named
263 .DE 437 .Fn profile ,
264 .P 438 in this mmh directory.
265 When the new attachment system was introduced, 439 Consistently, the context file and all the personal forms, scan formats,
266 .Pn viamail 440 and the like, are also there.
267 was removed because then 441 .P
268 .Pn forw 442 The naming changed with the relocation.
269 could cover the task itself. 443 The directory where everything, except the profile, had been stored (\c
270 The wrapper program 444 .Fn $HOME/Mail ),
271 .Pn sendfiles 445 used to be called \fIMH directory\fP. Now, this directory is called the
272 was rewritten as a shell script to use 446 user's \fImail storage\fP. The name \fImmh directory\fP is now given to
273 .Pn forw . 447 the new directory
274 .P 448 (\c
275 .Pn msgchk 449 .Fn $HOME/.mmh ),
276 was removed as it became hardly useful when POP support was removed. 450 containing all the personal configuration files.
277 It is questionable if 451 .P
278 .Pn msgchk 452 The separation of the files by type of content is logical and convenient.
279 provides more information than: 453 There are no functional differences as any possible setup known to me
280 .DS 454 can be implemented with both approaches, although likely a bit easier
281 ls -l /var/mail/meillo 455 with the new approach. The main goal of the change had been to provide
282 .DE 456 sensible storage locations for any type of personal mmh file.
283 It does separate between old and new mail, but that's not very 457 .P
284 useful and can be found out with 458 In order for one user to have multiple MH setups, he can use the
285 .Pn stat (1) 459 environment variable
286 too. A very small shell script could care for the form of output. 460 .Ev MH
287 As mmh's inc only incorporates mail from the user's local maildrop 461 the point to a different profile file.
288 and thus no long data transfers are involved, 462 The MH directory (mail storage plus personal configuration files) is
289 there's no need to check for new mail before incorporating it. 463 defined by the
290 .P 464 .Pe Path
291 .Pn msh 465 profile entry.
292 was removed because the tool was in conflict with the original 466 The context file could be defined by the
293 philosophy of MH. It provided an interactive shell to access the 467 .Pe context
294 features of MH. One major feature of MH is being a tool chest. 468 profile entry or by the
295 .Pn msh 469 .Ev MHCONTEXT
296 wouldn't be just another shell, tailored to the needs of mail 470 environment variable.
297 handling, but one large program to have the MH tools built in. 471 The latter is useful to have a distinct context (e.g. current folders)
298 It's main use was for accessing Bulletin Boards, which have seized to 472 in each terminal window, for instance.
299 be popular. Removing 473 In mmh, there are three environment variables now.
300 .Pn msh , 474 .Ev MMH
301 together with the truly obsolete programs 475 may be used to change the location of the mmh directory.
302 .Pn vmh 476 .Ev MMHP
303 and 477 and
304 .Pn wmh , 478 .Ev MMHC
305 saved more than 7\|000 lines of C code \(en a major achievement. 479 change the profile and context files, respectively.
306 480 Besides providing a more consistent feel (which simply is the result
307 481 of being designed anew), the set of personal configuration files can
308 .H1 "Draft and Trash Folders 482 be chosen independently from the profile (including mail storage location)
309 .U2 "Draft Folder 483 and context, now. Being it relevant for practical use or not, it
484 de-facto is an improvement. However, the main achievement is the
485 split between mail storage and personal configuration files.
486
487
488 .H2 "Modularization
489 .P
490 whatnowproc
491 .P
492 The \fIMH library\fP
493 .Fn libmh.a
494 collects a bunch of standard functions that many of the MH tools need,
495 like reading the profile or context files.
496 This doesn't hurt the separation.
497
498
499 .H2 "Style
500 .P
501 Code layout, goto, ...
502
503
504
505
506 .H1 "Concept Exploitation/Homogeniety
507
508
509 .H2 "Draft Folder
310 .P 510 .P
311 Historically, MH provided exactly one draft message, named 511 Historically, MH provided exactly one draft message, named
312 .Fn draft 512 .Fn draft
313 and 513 and
314 being located in the MH directory. When starting to compose another message 514 being located in the MH directory. When starting to compose another message
382 and name. 582 and name.
383 .P 583 .P
384 All theses changes converted special cases to regular cases, thus 584 All theses changes converted special cases to regular cases, thus
385 simplifying the tools and increasing the flexibility. 585 simplifying the tools and increasing the flexibility.
386 586
387 .U2 "Trash Folder 587
588 .H2 "Trash Folder
388 .P 589 .P
389 Similar to the situation for drafts is the situation for removed messages. 590 Similar to the situation for drafts is the situation for removed messages.
390 Historically, a message was deleted by renaming. A specific 591 Historically, a message was deleted by renaming. A specific
391 \fIbackup prefix\fP, often comma (\c 592 \fIbackup prefix\fP, often comma (\c
392 .Fn , ) 593 .Fn , )
469 .Sw \-unlink 670 .Sw \-unlink
470 switch causes the files to be truly unliked instead 671 switch causes the files to be truly unliked instead
471 of moved to the trash folder. 672 of moved to the trash folder.
472 673
473 674
474 .H1 "MH Directory Split 675 .H2 "Path Notations
475 .P
476 In MH and nmh, a personal setup had consisted of two parts:
477 The MH profile, named
478 .Fn \&.mh_profile
479 and being located directly in the user's home directory.
480 And the MH directory, where all his mail messages and also his personal
481 forms, scan formats, other configuration files are stored. The location
482 of this directory could be user-chosen. The default was to name it
483 .Fn Mail
484 and have it directly in the home directory.
485 .P
486 I've never liked the data storage and the configuration to be intermixed.
487 They are different kinds of data. One part, are the messages,
488 which are the data to operate on. The other part, are the personal
489 configuration files, which are able to change the behavior of the operations.
490 The actual operations are defined in the profile, however.
491 .P
492 When storing data, one should try to group data by its type.
493 There's sense in the Unix file system hierarchy, where configuration
494 file are stored separate (\c
495 .Fn /etc )
496 to the programs (\c
497 .Fn /bin
498 and
499 .Fn /usr/bin )
500 to their sources (\c
501 .Fn /usr/src ).
502 Such separation eases the backup management, for instance.
503 .P
504 In mmh, I've reorganized the file locations.
505 Still there are two places:
506 There's the mail storage directory, which, like in MH, contains all the
507 messages, but, unlike in MH, nothing else.
508 Its location still is user-chosen, with the default name
509 .Fn Mail ,
510 in the user's home directory. This is much similar to the case in nmh.
511 The configuration files, however, are grouped together in the new directory
512 .Fn \&.mmh
513 in the user's home directory.
514 The user's profile now is a file, named
515 .Fn profile ,
516 in this mmh directory.
517 Consistently, the context file and all the personal forms, scan formats,
518 and the like, are also there.
519 .P
520 The naming changed with the relocation.
521 The directory where everything, except the profile, had been stored (\c
522 .Fn $HOME/Mail ),
523 used to be called \fIMH directory\fP. Now, this directory is called the
524 user's \fImail storage\fP. The name \fImmh directory\fP is now given to
525 the new directory
526 (\c
527 .Fn $HOME/.mmh ),
528 containing all the personal configuration files.
529 .P
530 The separation of the files by type of content is logical and convenient.
531 There are no functional differences as any possible setup known to me
532 can be implemented with both approaches, although likely a bit easier
533 with the new approach. The main goal of the change had been to provide
534 sensible storage locations for any type of personal mmh file.
535 .P
536 In order for one user to have multiple MH setups, he can use the
537 environment variable
538 .Ev MH
539 the point to a different profile file.
540 The MH directory (mail storage plus personal configuration files) is
541 defined by the
542 .Pe Path
543 profile entry.
544 The context file could be defined by the
545 .Pe context
546 profile entry or by the
547 .Ev MHCONTEXT
548 environment variable.
549 The latter is useful to have a distinct context (e.g. current folders)
550 in each terminal window, for instance.
551 In mmh, there are three environment variables now.
552 .Ev MMH
553 may be used to change the location of the mmh directory.
554 .Ev MMHP
555 and
556 .Ev MMHC
557 change the profile and context files, respectively.
558 Besides providing a more consistent feel (which simply is the result
559 of being designed anew), the set of personal configuration files can
560 be chosen independently from the profile (including mail storage location)
561 and context, now. Being it relevant for practical use or not, it
562 de-facto is an improvement. However, the main achievement is the
563 split between mail storage and personal configuration files.
564
565
566 .H1 "Path Notations
567 .P 676 .P
568 foo 677 foo
569 678
570 .H1 "Attachments 679
571 .P 680 .H2 "MIME Integration
572 foo 681 .P
573
574 .H1 "mhshow to show Transition
575 .P
576 Since the very beginning, already in the first concept paper,
577 .Pn show
578 had been MH's mail display program.
579 .Pn show
580 found out which pathnames the relevant messages had and invoked
581 .Pn mhl
582 then to let it render the content.
583 With the advent of MIME, this approach wasn't sufficient anymore.
584 MIME messages can consist of multiple parts, some of which aren't
585 directly displayable, and text content can be encoded in
586 foreign charsets.
587 .Pn show 's
588 simple approach and
589 .Pn mhl 's
590 limited display facilities couldn't cope with the task any longer.
591 Instead of extending these tools, new ones were written from scratch
592 and then added to the MH tool chest. Doing so is encouraged by the
593 tool chest approach. The new tools could be added without interfering
594 with the existing ones. This is great. It allowed MH to be the
595 first MUA to implement MIME.
596 .P
597 The new MIME features were added in form of the single program
598 .Pn mhn .
599 The command
600 .DS
601 mhn \-show 42
602 .DE
603 would show the MIME message numbered 42.
604 With the 1.0 release of nmh in February 1999, Richard Coleman finished
605 the split of
606 .Pn mhn
607 into a set of specialized programs, which together covered the
608 aspects of MIME. One of these resulting tools was
609 .Pn mhshow .
610
611
612 .H1 "Blind Carbon Copies
613 .P
614 foo
615
616 .H1 "Good Defaults
617 .P
618 foo
619
620 .H1 "Modularization
621 .P
622 foo
623
624 .H1 "Code style
625 .P
626 foo
627
628
629
630 (e.g. the
631 user-visible access to whole messages and MIME parts are inherently 682 user-visible access to whole messages and MIME parts are inherently
632 different). 683 different
633 684
634 The \fIMH library\fP 685
635 .Fn libmh.a 686 .H2 "Of One Cast
636 collects a bunch of standard functions that many of the MH tools need, 687 .P
637 like reading the profile or context files.
638 This doesn't hurt the separation.
639