docs/master
view ch01.roff @ 39:22ae3981a76b
style: New RN macro to reset page numbers and change their style.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Tue, 15 May 2012 22:11:16 +0200 |
| parents | 6a9abf543297 |
| children | af8c46461924 |
line source
1 .RN 1
3 .H0 "Introduction
4 .P
5 This chapter introduces MH, its history, concepts and how it is used.
6 Then, it describes nmh's code base and community to give the reader
7 a better understanding of the state from which mmh started off.
8 Further more, this chapter lists the motivation and goals of the mmh project.
9 This chapter introduces MH, nmh and mmh to the reader and outlines
10 the mmh project itself.
13 .H1 "MH \(en the Mail Handler
14 .P
15 MH is an electronic mail system, originating in the RAND Corporation.
16 Most important for this thesis is that MH defines a mail handling concept.
17 In fact, MH had started as a design proposal, not as an implementation,
18 and in spirit it had remained this way. This is similar to Unix, which
19 influenced the world rather in being a set of system design concepts
20 than in being a specific software product.
21 .P
22 XXX Link to the Unix phil.
23 .P
24 XXX comparision to monolithic mail systems.
25 .P
26 XXX Differenciation of MUA and mail system.
28 .U2 "History
29 .P
30 MH is an electronic mail system, originating in the RAND Corporation.
31 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
32 had proposed the design
33 of a new mail handling system, called ``Mail Handler'' (MH),
34 to superseed RAND's old monolithic ``Mail System'' (MS).
35 Two years later, in 1979, Bruce Borden took the proposal and implemented a
36 prototype of MH.
37 Before the prototype had been available, the concept was
38 believed to be practically unusable because of being too slow.
39 But the prototype proved successful and replaced MS thereafter.
40 In replacing MS, MH became an all-in-one mail system.
41 .P
42 A decade later, the University of California at Irvine had started to use MH.
43 They also took over its development and pushed MH forward.
44 This was the time when the Internet appeared, UCB implemented
45 the TCP/IP stack, and Allman wrote Sendmail.
46 MH was extended as emailing got more features.
47 The development of MH was closely related to the development of email
48 RFCs. In the advent of MIME, MH was the first implementation of this new
49 email standard.
50 .P
51 In the nineties, MH had been moved into the public domain, making it
52 attractive to Free Software developers.
53 The Internet had started to become popular and in 1997,
54 Richard Coleman initiated the ``New Mail Handler'' (nmh) project,
55 a fork of MH, based on the \fILBL changes\fP by Van Jacobson, Mike Karels
56 and Craig Leres.
57 Colman intended to modernize MH and improve its portability and
58 MIME handling capabilities.
59 This should be done openly within the Internet community.
60 The development of MH stopped soon after the development of nmh had started.
61 Today, nmh almost completely replaced the original MH.
63 .U2 "Concepts
64 .P
65 MH is a toolchest, modelled after the Unix toolchest. It consists of a
66 set of tools, each covering a specific task of email handling. The programs
67 operate on a common mail storage. The specific format of the mail storage
68 characterizes MH in the same way like the format of the file system
69 characterizes Unix.
70 The mail storage consists of \fImail folders\fP (directories) and
71 \fPmessages\fP (regular files).
72 Each message is stored in a separate file in the format it had been
73 received (i.e. transfer format). The files are named with ascending numbers
74 in each folder.
75 MH tools maintain a \fIcontext\fP, which includes
76 the current mail folder and current message.
77 Processes in Unix have a similar context, containing the current working
78 directory, for instance. In contrast, the process context is maintained
79 by the Unix kernel automatically, whereas MH tools need to maintain the MH
80 context themselves.
81 The user can have one MH context or multiple ones, he can even share it
82 with other users.
83 Messages can have symbolic names. These can be automatically updated
84 position names like being the next or the last message,
85 or user-settable group names for arbitrary sets of messages.
86 These names are called sequences.
87 Sequences can be bound to the folder or to the context.
88 .P
89 New MH tools are built out of or on top of existing ones easily \(en
90 a property common to toolchests.
91 Multiple versions of the same command with different default values
92 are created very easily. This provides shortcuts and tayloring.
93 Form templates for new messages or for replies are easily exchangable.
94 Generally, output is adjustable with format files.
95 The configuration is stored in a file that is called the user's \fIprofile\fP.
96 MH encourages the user to taylor and automate the mail handling.
97 Almost everypart of the system can be adjusted to personal preference.
98 The system is well scriptable and extendable.
99 As the MH toolchest was modelled after the Unix toolchest, the
100 properties of the latter apply to the former as well.
102 .U2 "Versions
103 .P
104 Three versions of MH are available today:
105 .IP "Old MH"
106 In most cases this version had been replaced by nmh,
107 but some systems might still provide old MH.
108 The main reasons to still use old MH are historical reasons.
109 MH provides hardly any benefits over nmh.
110 The development of old MH has stopped after the 6.8.4 release in
111 February 1996.
112 .IP nmh\0
113 The most widespread version of MH was forked off version 6.8.3 in December
114 1996. It is based on the \fILBL changes\fP.
115 Backward-compatibility to old MH is provided by having new featues deactivated
116 by default. In consequence, the user needs to activate them explicitely to
117 be able to use them.
118 Throughout the previous years, the work on nmh was mostly maintenance work.
119 Development revived in December 2011 and stayed busy since then.
120 .IP mmh
121 This descendent of nmh is the subject of this thesis.
122 It had started as an experimental version, but became de facto a fork.
124 .U2 "Example Session
125 .P
126 Following is an example mail handling session with mmh.
127 It should be mostly compatible with nmh and old MH.
128 Details might vary but the look'n'feel is the same.
129 .P
130 XXX shell mail handling session follows ...
133 .H1 "nmh: Code and Community
134 .P
135 In order to understand the state, goals and dynamics of a project,
136 one needs to know its history. MH comes from a time before the
137 Internet, a time before networking became universal, a time when
138 emailing was small, short and simple. Then it grew, spread and
139 adopted to the changes. The core-concepts, however, remained the
140 same. During the XXX a small group of students at the University of
141 California, actively worked on MH. They added features and optimized,
142 like it is common for scientific work. This is still in pre-ANSI C
143 times. The source code contains many ancient parts. Code constructs
144 specific to BSD or hardware of that time are usual.
145 .P
146 Nmh started eight years after the ANSI C standard had been
147 established. A more modern coding style entered the code base. Still
148 a part of the developers come from ``the old days''. The developer
149 base became more diverse and thus the code. Programming practices
150 from different decades merged into the project. Different coding
151 styles came together. It appears as if multiple peers added code
152 parts, resulting in a conclomeration rather than an homogenic
153 of-one-cast mail system. Still, the basic concepts hold it together.
154 They were mostly untouched throughout the years.
155 .P
156 Although, at the surface, nmh is a toolchest, meaning a collection
157 of completely modularized small programs, on the source code level,
158 it is much more interweaved. Parts of the basic functions are
159 collected in a MH standard library, which is good, but often
160 separate functions are compiled into programs, for effiency reasons.
161 This lead to intricate innards.
162 The advent of MIME rose the complexity of email by a magnitude. This
163 is visible in nmh. The MIME-related parts are the most complex ones.
164 It's also visible that MIME support had been added on top of the
165 old MH later. The MH style made this easily possible, but it
166 also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
167 and had not been thoroughly included into the concepts (e.g. the
168 user-visible access to whole messages and MIME parts are inherently
169 different).
170 .P
171 For compatibility's sake, it is a common understanding to have the
172 default settings to be compatible, requiring any new feature to be
173 explicitely enabled. This puts a burden on new users, because nmh
174 out-of-the-box keeps staying in the same ancient style, where users
175 usually want to have it practical for modern emailing.
176 But of course, this depends on if nmh is seen to be a front-end or a
177 back-end.
180 .H1 "mmh
181 .P
182 I started to work on my experimental version, which I call
183 \fImmh\fP (for \fImeillo's mail handler\fP), in Fall 2011.
184 In December, when I announced that I would work on an experimental
185 version, the activity in nmh suddenly rose. Suddently the community
186 started to move.
187 After long years of mostly idling, nmh became actively developed again.
188 What a great result!
189 Hence, while I was working on mmh, the community was working on nmh
190 too. My own work went in parallel and mostly unrelated.
191 .P
192 Because of several circumstances, my experimental version is rather
193 a fork today, although this may change again in the future.
195 .U2 "Motivation
196 .P
197 XXX
199 .U2 "Why it is worth it
200 .P
201 XXX
203 .U2 "Target Field
204 .P
205 XXX Target field and scenarios
206 .P
207 The target user in mind likes Unix and its philosophy.
208 He likes to use programs that are conceptionally appealing.
209 He's familiar with the command line and enjoys its power.
210 He is at least capable of shell scripting and wants to improve his
211 productivity by scripting the mail system.
212 His computer and operating system are from post-ANSI C times.
213 He likes to attach files, exchanges text containing non-ASCII
214 characters, signs or encrypts his messages.
215 He does not use bulletin boards anymore, nor non-mbox style mail
216 drops, nor does he rely on compatibility to nmh.
217 He already has and MTA/MSA and MRA running or is able to set them
218 up.
219 He does not want to have to read a book in order to make his MUA
220 usable.
221 .P
222 XXX Limitations
224 .U2 "The Vision
225 .P
226 The general goals of the mmh project are the following:
227 .BU
228 I believe that mmh should be perfectly suited for modern emailing,
229 out-of-the-box.
230 .BU
231 I care less about compatibility and more about conceptionally elegant
232 approaches.
233 .BU
234 I care for general, clear, and simple concepts.
235 .BU
236 I like to create an of-one-style email system. It should feel like
237 cast as one.
238 .BU
239 I plan to remove any optimizations that rises obscurity, unless it
240 appears to be neccessary to make mmh usable at all.
242 .U2 "Work to do
243 .BU
244 Remove the MTA and MRA facilities. Mmh shall concentrate on the MUA
245 task. Mail shall enter mmh's mail storage via the system mail drop
246 and it shall leave mmh via the local \fLsendmail\fP command.
247 .BU
248 Remove any further functions that are not related to mmh's main task.
249 Bulletin board support is on example. Also remove support for ancient
250 technologies, like hardcopy terminals.
251 .BU
252 Refactor the source code to meet modern style criteria. Use
253 standardized library functions when possible.
254 .BU
255 Replace performance optimizations by clear and readable code.
256 .BU
257 Reduce the feature set to the commonly used one, removing
258 corner-cases. Set sane default values.
259 .BU
260 Add better attachment support. Add support for digital signatures and
261 encryption.
262 .BU
263 Merge \fLshow\fP and \fLmhshow\fP into one single mail display program.
264 Integrate MIME support deeper and more natural into MH.
265 .BU
266 Provide a ready-to-use setup out-of-the-box.
269 .H1 "Goals of this Thesis
271 .U2 "Methods
272 .P
273 foo