Mercurial > docs > master

comparison ch01.roff @ 32:6a9abf543297

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Rework in the Introduction (about MH).
author markus schnalke <meillo@marmaro.de>
date Mon, 14 May 2012 17:10:43 +0200
parents 6c63083b4c19
children 22ae3981a76b
comparison
equal deleted inserted replaced
31:029e11dd4de1 32:6a9abf543297
1 .H0 "Introduction 1 .H0 "Introduction
2 .P 2 .P
3 This chapter describes the background of the topics in this thesis. 3 This chapter introduces MH, its history, concepts and how it is used.
4 General knowledge of electronic mail is assumed. 4 Then, it describes nmh's code base and community to give the reader
5 It explains the situation at the start of the project. 5 a better understanding of the state from which mmh started off.
6 It tries to describe from what state the project lifted of and where 6 Further more, this chapter lists the motivation and goals of the mmh project.
7 it headed to. This shall give an overview. 7 This chapter introduces MH, nmh and mmh to the reader and outlines
8 the mmh project itself.
8 9
9 10
10 .H1 "MH \(en the Mail Handler 11 .H1 "MH \(en the Mail Handler
11 .P 12 .P
12 MH is an electronic mail system, originating in the RAND Corporation. 13 MH is an electronic mail system, originating in the RAND Corporation.
13 Historically, it had been a all-in-one mail system, with both Mail Transfer 14 Most important for this thesis is that MH defines a mail handling concept.
14 Agent (MTA) and Mail User Agent (MUA). 15 In fact, MH had started as a design proposal, not as an implementation,
15 Later, when email setups changed, Mail Submission Agent (MSA) 16 and in spirit it had remained this way. This is similar to Unix, which
16 and Mail Retrieval Agent (MRA) facilities were added. 17 influenced the world rather in being a set of system design concepts
17 The MTA became less important, whereas the MUA became even more the 18 than in being a specific software product.
18 central part.
19 .P
20 MH defines a mail handling concept.
21 It had started as a design proposal, not as an implementation, and
22 in spirit had remained this way. This is similar to Unix, which
23 rather is a style of system design than specific software product.
24 .P 19 .P
25 XXX Link to the Unix phil. 20 XXX Link to the Unix phil.
26 .P 21 .P
27 XXX comparision to monolithic mail systems. 22 XXX comparision to monolithic mail systems.
28 .P 23 .P
29 XXX Differenciation of MUA and mail system. 24 XXX Differenciation of MUA and mail system.
30 25
31 .U2 "History 26 .U2 "History
32 .P 27 .P
33 MH is an electronic mail system, originating in the RAND Corporation. 28 MH is an electronic mail system, originating in the RAND Corporation.
34 In 1977, Norman Shapiro and Stockton Gaines had proposed the design 29 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
35 of a new mail handling system, called ``Mail Handler'' (MH) for RAND, 30 had proposed the design
36 to superseed their ``Mail System'' (MS). 31 of a new mail handling system, called ``Mail Handler'' (MH),
32 to superseed RAND's old monolithic ``Mail System'' (MS).
37 Two years later, in 1979, Bruce Borden took the proposal and implemented a 33 Two years later, in 1979, Bruce Borden took the proposal and implemented a
38 prototype of MH. It proved successful and replaced MS thereafter. 34 prototype of MH.
39 .P 35 Before the prototype had been available, the concept was
40 A decade later, the University of California had started to use MH. 36 believed to be practically unusable because of being too slow.
37 But the prototype proved successful and replaced MS thereafter.
38 In replacing MS, MH became an all-in-one mail system.
39 .P
40 A decade later, the University of California at Irvine had started to use MH.
41 They also took over its development and pushed MH forward. 41 They also took over its development and pushed MH forward.
42 This had been the time when the Internet appeared, Berkeley implemented 42 This was the time when the Internet appeared, UCB implemented
43 the TCP stack, and Sendmail was born. MH had often contained the first 43 the TCP/IP stack, and Allman wrote Sendmail.
44 implementation of new RFCs. 44 MH was extended as emailing got more features.
45 The development of MH was closely related to the development of email
46 RFCs. In the advent of MIME, MH was the first implementation of this new
47 email standard.
45 .P 48 .P
46 In the nineties, MH had been moved into the public domain, making it 49 In the nineties, MH had been moved into the public domain, making it
47 attractive to Free Software developers. The Internet had started to become 50 attractive to Free Software developers.
48 mainstream and in 1997, Richard Coleman initiated the ``New Mail Handler'' 51 The Internet had started to become popular and in 1997,
49 (nmh), a fork of MH. He intended to modernize MH, improve its MIME 52 Richard Coleman initiated the ``New Mail Handler'' (nmh) project,
50 capabilities, and this should be done openly within the Internet 53 a fork of MH, based on the \fILBL changes\fP by Van Jacobson, Mike Karels
51 community. Today, nmh almost completely replaced the original MH. 54 and Craig Leres.
55 Colman intended to modernize MH and improve its portability and
56 MIME handling capabilities.
57 This should be done openly within the Internet community.
58 The development of MH stopped soon after the development of nmh had started.
59 Today, nmh almost completely replaced the original MH.
52 60
53 .U2 "Concepts 61 .U2 "Concepts
54 .P 62 .P
55 MH is a toolchest, modelled after the Unix toolchest. It consists of a 63 MH is a toolchest, modelled after the Unix toolchest. It consists of a
56 bunch of tools, each covering one task of email handling. These programs 64 set of tools, each covering a specific task of email handling. The programs
57 operate on a common mail storage. The specific format of the mail storage 65 operate on a common mail storage. The specific format of the mail storage
58 also defines MH, like the file system structure defines Unix. It 66 characterizes MH in the same way like the format of the file system
59 consists of directories (mail folders) and files (mail messages). 67 characterizes Unix.
60 Each file contains exactly one message in the format it had been 68 The mail storage consists of \fImail folders\fP (directories) and
61 received (i.e. transfer format). MH tools carry a state (context), 69 \fPmessages\fP (regular files).
62 consisting of current mail folder and current message. Messages can 70 Each message is stored in a separate file in the format it had been
63 have symbolic names, like the next or last message or for some 71 received (i.e. transfer format). The files are named with ascending numbers
64 arbitrary group of messages. These names are called sequences. 72 in each folder.
65 .P 73 MH tools maintain a \fIcontext\fP, which includes
66 New MH tools can be build out of existing ones easily. Default values to 74 the current mail folder and current message.
67 commands are stored on a command name-basis, making it trivial to have 75 Processes in Unix have a similar context, containing the current working
68 different versions of the same command with different defaults. Most 76 directory, for instance. In contrast, the process context is maintained
69 of the configuration is stored in the user's profile. Form templates, 77 by the Unix kernel automatically, whereas MH tools need to maintain the MH
70 e.g. for new messages or replies, are exchangeable and output is generally 78 context themselves.
71 adjustable with format files. 79 The user can have one MH context or multiple ones, he can even share it
72 .P 80 with other users.
73 MH allows the user to automate almost everything and to modify amost 81 Messages can have symbolic names. These can be automatically updated
74 any behavior. The system is scriptable and extendable. 82 position names like being the next or the last message,
75 83 or user-settable group names for arbitrary sets of messages.
76 .U2 "Available Versions 84 These names are called sequences.
85 Sequences can be bound to the folder or to the context.
86 .P
87 New MH tools are built out of or on top of existing ones easily \(en
88 a property common to toolchests.
89 Multiple versions of the same command with different default values
90 are created very easily. This provides shortcuts and tayloring.
91 Form templates for new messages or for replies are easily exchangable.
92 Generally, output is adjustable with format files.
93 The configuration is stored in a file that is called the user's \fIprofile\fP.
94 MH encourages the user to taylor and automate the mail handling.
95 Almost everypart of the system can be adjusted to personal preference.
96 The system is well scriptable and extendable.
97 As the MH toolchest was modelled after the Unix toolchest, the
98 properties of the latter apply to the former as well.
99
100 .U2 "Versions
77 .P 101 .P
78 Three versions of MH are available today: 102 Three versions of MH are available today:
79 .BU 103 .IP "Old MH"
80 .I "Original MH" . 104 In most cases this version had been replaced by nmh,
81 In most cases it has been replaced by nmh, but some systems still 105 but some systems might still provide old MH.
82 provide old MH. As nmh is old MH-compatible, there exist few reasons 106 The main reasons to still use old MH are historical reasons.
83 not to upgrade to new. 107 MH provides hardly any benefits over nmh.
84 The development of old MH has stopped after the 6.8.4 release in 108 The development of old MH has stopped after the 6.8.4 release in
85 February 1996. 109 February 1996.
86 .BU 110 .IP nmh\0
87 .I nmh .
88 The most widespread version of MH was forked off version 6.8.3 in December 111 The most widespread version of MH was forked off version 6.8.3 in December
89 1996. It incorporated the \fILBL changes\fP. 112 1996. It is based on the \fILBL changes\fP.
90 It provides backward-compatible to old MH by having new featues deactivated 113 Backward-compatibility to old MH is provided by having new featues deactivated
91 by default. To use them, the user needs to activate them explicitely. 114 by default. In consequence, the user needs to activate them explicitely to
92 Its development went slowly in the previous years, but had revived 115 be able to use them.
93 in December 2011. 116 Throughout the previous years, the work on nmh was mostly maintenance work.
94 .BU 117 Development revived in December 2011 and stayed busy since then.
95 .I mmh . 118 .IP mmh
96 This version is the subject of this thesis. 119 This descendent of nmh is the subject of this thesis.
97 It is a descendent of nmh. It had started as a non-compatible experimental 120 It had started as an experimental version, but became de facto a fork.
98 version, but became de facto a fork. It tries to expand the same
99 principle concepts in a more modern way.
100 121
101 .U2 "Example Session 122 .U2 "Example Session
102 .P 123 .P
103 Example mail handling session with mmh, but mostly compatible with nmh 124 Following is an example mail handling session with mmh.
104 and old MH. The look'n'feel is common among them. 125 It should be mostly compatible with nmh and old MH.
126 Details might vary but the look'n'feel is the same.
127 .P
128 XXX shell mail handling session follows ...
105 129
106 130
107 .H1 "nmh: Code and Community 131 .H1 "nmh: Code and Community
108 .P 132 .P
109 In order to understand the state, goals and dynamics of a project, 133 In order to understand the state, goals and dynamics of a project,
134 separate functions are compiled into programs, for effiency reasons. 158 separate functions are compiled into programs, for effiency reasons.
135 This lead to intricate innards. 159 This lead to intricate innards.
136 The advent of MIME rose the complexity of email by a magnitude. This 160 The advent of MIME rose the complexity of email by a magnitude. This
137 is visible in nmh. The MIME-related parts are the most complex ones. 161 is visible in nmh. The MIME-related parts are the most complex ones.
138 It's also visible that MIME support had been added on top of the 162 It's also visible that MIME support had been added on top of the
139 original MH later. The MH style made this easily possible, but it 163 old MH later. The MH style made this easily possible, but it
140 also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP) 164 also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
141 and had not been thoroughly included into the concepts (e.g. the 165 and had not been thoroughly included into the concepts (e.g. the
142 user-visible access to whole messages and MIME parts are inherently 166 user-visible access to whole messages and MIME parts are inherently
143 different). 167 different).
144 .P 168 .P