docs/master
view intro.roff @ 230:96778c1afc3e
More cleanups.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Mon, 16 Jul 2012 00:37:31 +0200 |
| parents | 157c92fc1597 |
| children | 77c87c38bff4 |
line source
1 .RN 1
2 .H0 "Introduction
3 .Id introduction
5 .P
6 MH is a set of mail handling tools with a common concept.
7 It is similar to the Unix tool chest, which is a set of file
8 handling tools with a common concept.
9 \fInmh\fP is the currently most popular implementation of an
10 MH-like mail handling system.
11 This thesis describes an experimental version of nmh, named \fImmh\fP.
12 .P
13 This chapter introduces MH, its history, concepts and how it is used.
14 It describes nmh's code base and community to give the reader
15 a better understanding of the project's condition at the time when
16 mmh started off.
17 Furthermore, this chapter outlines the mmh project itself,
18 describing the motivation for it and its goals.
21 .H1 "MH \(en the Mail Handler
22 .Id mh
23 .P
24 MH is a conceptual email system design and its concrete implementation.
25 MH had started as a design proposal at RAND Corporation,
26 where the first implementation followed later.
27 In spirit, MH is similar to Unix, which
28 influenced the world more in being a set of system design concepts
29 than in being a specific software product.
30 The ideas behind Unix are summarized in the \fIUnix philosophy\fP.
31 .[
32 gancarz unix philosophy
33 .]
34 MH follows this philosophy.
36 .U2 "History
37 .P
38 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
39 proposed the design of a new mail handling system,
40 .[
41 shapiro gaines mh proposal
42 .]
43 to superseed RAND's old monolithic \fIMail System\fP (MS).
44 One year later, in 1978, Bruce Borden picked up on the
45 proposal and implemented a prototype, which he called
46 \fIMail Handler\fP (MH).
47 Before the prototype's existence, the concept was
48 believed to be practically unusable.
49 But the prototype \(en written in only three weeks \(en
50 proved successful and replaced MS thereafter.\&
51 .[ [
52 rand note design of mh
53 .], p. 4]
54 .P
55 In the early eighties,
56 the University of California at Irvine (UCI) started to use MH.
57 Marshall T. Rose and John L. Romine then became the driving force.
58 They took over the development and pushed MH forward.
59 .[ [
60 rand note design of mh
61 .], p. 4]
62 RAND had put the code into the public domain by then.
63 MH was developed at UCI at the same time when the Internet appeared,
64 BSD started to support TCP/IP networking,
65 and Eric Allman wrote Sendmail.
66 MH was extended as emailing became more featured.
67 The development of MH was closely related to the development of email RFCs.
68 In the advent of the \fIMultipurpose Internet Mail Extensions\fP (MIME),
69 MH was one of the first implementations of the new email standard.
70 .P
71 In the nineties, the Internet became popular and in December 1996,
72 Richard Coleman initiated the \fINew Mail Handler\fP (nmh) project.
73 Nmh is a fork of MH 6.8.3 and bases heavily on the
74 \fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres.
75 .[
76 lbl changes
77 .]
78 Colman intended to modernize MH and improve its portability and
79 MIME handling capabilities.
80 The development of MH at UCI stopped after the 6.8.4 release in
81 February 1996, soon after the development of nmh had started.
82 Today, nmh is developed openly in the Internet community.
83 It has almost completely replaced the original MH.
84 Some systems might still provide the old MH, but hardly for good reasons.
85 .P
86 In the last years, the majority of changes in nmh was maintenance work.
87 Nevertheless, the development was revived in December 2011
88 and stayed busy since then.
91 .U2 "Concepts
92 .P
93 MH consists of a set of tools, each covering a specific task of
94 email handling, such as composing a message, replying to a message,
95 refiling a message to a different folder, listing the messages in a folder.
96 The tools are invoked directly from the Unix shell.
97 .[
98 a rand note design of mh
99 .]
100 .P
101 The tools operate on a common mail storage, which consists of
102 \fImail folders\fP (directories) and \fPmessages\fP (regular files).
103 Each message is stored in a separate file.
104 .[
105 a rand note design of mh
106 .]
107 The files are named with ascending numbers in each folder.
108 The specific format of the mail storage characterizes MH in the same way
109 as the format of the file system characterizes Unix.
110 .P
111 MH tools maintain a \fIcontext\fP, which includes for instance the
112 current mail folder.
113 Processes in Unix have a similar context, containing the current working
114 directory, for instance. In contrast, the process context is maintained
115 by the Unix kernel automatically, whereas MH tools need to maintain the MH
116 context themselves.
117 The user can have one MH context or multiple ones; he can even share it
118 with others.
119 .P
120 Messages are named by their numeric filename,
121 but they can have symbolic names, as well.
122 These are either one of six system-controlled position names
123 and a shorthand for the range of all messages,
124 or user-settable group names for arbitrary sets of messages.
125 These names are called sequences.
126 Automatically updated position names exist for the
127 first, last, previous, next, current message, and for the number
128 one beyond the last message.
129 (In mmh, the names of these sequences are abbreviated to the
130 first character.)
131 User-defined sequences can be bound to the folder containing the
132 messages (\fIpublic sequences\fP) or to the user's context
133 (\fIprivate sequences\fP).
134 .P
135 The user's \fIprofile\fP is the file that contains his MH configuration.
136 Default switches for the individual tools can be specified to
137 adjust them to the user's personal preferences.
138 These switches will be automatically supplied whenever the specific
139 tool is invoked.
140 Additionally, a single command can be linked under different names
141 with different default values.
142 Form templates for new messages and replies, as well as format files
143 to adjust the output of tools are easily exchanged in the profile.
144 Almost every part of the system can be adjusted to personal preference.
145 .P
146 The whole system is well scriptable and extensible.
147 New MH tools are built out of or on top of existing ones quickly.
148 MH encourages the user to tailor, extend, and automate the system.
149 As the MH tool chest was modeled after the Unix tool chest, the
150 properties of the latter apply to the former as well.
154 .U2 "Using MH
155 .P
156 Many tutorials to using MH
157 .[
158 rose sweet mh tutorial
159 .]
160 .[
161 moss jackson user's guide for mh
162 .]
163 .[
164 hegardt mh for beginners
165 .]
166 are old, but still they teach the concepts and basics,
167 which remained unchanged.
168 Rose and Romine have written an excellent introduction on a more
169 technical level, with pointers to advanced usage.
170 .[
171 rose romine real work
172 .]
173 For a more recent document, it is strongly recommended to have
174 a look at the \fIMH Book\fP,
175 .[ [
176 peek mh book
177 .], Part II]
178 especially at its online version.
179 .P
180 Following here is a sample mail handling session with mmh.
181 Details might vary to MH and nmh but the look and feel is the same.
183 .so input/mh-session
186 .H1 "nmh
187 .P
188 In order to understand the condition, goals and dynamics of a project,
189 one needs to know the reasons behind them.
190 This section gives background information.
191 .P
192 MH predates the Internet;
193 it comes from times before networking was universal;
194 it comes from times when emailing was small, short and simple.
195 Then, MH grew, spread and adapted to the changes email went through.
196 Its core concepts, however, remained the same.
197 During the eighties, students at UCI actively worked on MH.
198 They added new features and optimized the code for the systems
199 popular at that time.
200 This was in times before POSIX and ANSI C.
201 As large parts of the code stem from this time, today's nmh source code
202 still contains many ancient parts.
203 BSD-specific code and constructs tailored for hardware of that time
204 are frequent.
205 .P
206 Nmh started about one decade after the POSIX and ANSI C standards were
207 released.
208 A more modern coding style entered the code base but still
209 a part of the developers were ``of the old type''.
210 The developer base became more diverse,
211 thus broadening the range of different coding styles.
212 Programming practices from different decades merged in the project.
213 As several peers added code, the system became more a conglomeration
214 of single tools rather than a homogeneous of-one-cast mail system.
215 For that, leadership would have been necessary.
216 Nevertheless, MH's basic concepts held the project together.
217 They were mostly untouched throughout the years.
218 .P
219 Though clearly separated on the surface
220 \(en as a collection of small, separate programs \(en
221 the source code turns out to be fairly interwoven.
222 Multiple separate components are compiled into a program
223 for efficiency reasons.
224 This leads to intricate innards.
225 .P
226 It is visible in nmh that
227 the advent of MIME raised the complexity of email by a magnitude.
228 The MIME-related parts are the most complex ones.
229 It is also visible that MIME support was added on top of the old MH core.
230 MH's tool chest style made this easily possible and encourages
231 such approaches, but unfortunately, it led to duplicated functions
232 and half-hearted implementation of concepts.
233 .P
234 To provide backward-compatibility, it is a common understanding
235 in the nmh community to not change the default settings.
236 In consequence, users need to activate modern features explicitly
237 to be able to use them.
238 The ancient style in which fresh nmh setups remain to appear
239 causes difficulties for new users, as modern email features require
240 additional configuration.
241 The small but mature community around nmh, however, needs little change
242 as they have had their convenient setups for decades.
245 .H1 "mmh
246 .P
247 I started to work on my experimental version in October 2011,
248 basing my work on nmh version \fInmh-1.3-dev\fP.
249 At that time no more than three commits were made to nmh
250 since the beginning of 2011, the latest one being
251 .Ci a01a41d031c796b526329a4170eb23f0ac93b949 ,
252 committed on 2011-04-13.
253 In December, when I announced my work in progress on the
254 nmh-workers mailing list,
255 .[
256 nmh-workers mmh announce December
257 .]
258 nmh's community became active, all of a sudden.
259 This movement was heavily pushed by Paul Vixie's ``edginess'' comment.
260 .[
261 nmh-workers vixie edginess
262 .]
263 After long years of stagnation, nmh became actively developed again.
264 Hence, while I was working on mmh, the community was working on nmh,
265 in parallel but unrelated.
266 .P
267 The name \fImmh\fP may stand for \fImodern mail handler\fP,
268 because the project tries to modernize nmh.
269 Personally however, I prefer to call mmh \fImeillo's mail handler\fP,
270 emphasizing that the project is my version of nmh,
271 following my visions and preferences.
272 (My login name is \fImeillo\fP.)
273 This project model was inspired by \fIdwm\fP,
274 which is Anselm Garbe's personal window manager \(en
275 targeted to satisfy Garbe's personal needs whenever conflicts appear.
276 Dwm has retained its lean elegance and its focused character,
277 .[
278 dwm ohloh
279 .]
280 whereas its community-driven predecessor \fIwmii\fP had grown
281 fat over time.
282 .[
283 wmii ohloh
284 .]
285 The development of mmh should remain focused.
288 .U2 "Motivation
289 .P
290 MH is the most important of very few email systems in a tool chest style.
291 Tool chests are powerful because they can be perfectly automated and
292 extended.
293 They allow the implementation of arbitrary kinds of front-ends
294 on top of the tool chest quickly and without internal knowledge.
295 Additionally, tool chests are easier to maintain than monolithic
296 programs.
297 .[ [
298 gancarz unix phil
299 .], p. 14]
300 MH-like email tool chests should be kept alive as they fill a market
301 niche by providing conceptional elegance and unique scripting qualities.
302 Mmh tries to create a modern and convenient entry point to MH-like
303 systems for new and interested users.
304 .P
305 The mmh project is motivated by deficits of nmh and
306 by my wish for general changes.
307 At the time the mmh project started, nmh had not yet adjusted to
308 modern emailing needs well enough.
309 The default setup was completely unusable for modern emailing.
310 Too much setup work was required.
311 Several modern features were already available,
312 but the community did not want to have them active by default.
313 Mmh is my way to change this.
314 .P
315 In my eyes, MH's concepts could be exploited better and
316 the style of the tools could be improved.
317 Both would simplify and generalize the system, providing cleaner
318 interfaces and greater software leverage at the same time.
319 Mmh is my way to demonstrate this.
320 .P
321 In providing multiple parts of the email system, nmh can hardly
322 compete with the large specialized projects that focus
323 on one of the components only.
324 The situation could be improved by concentrating the development power
325 on the most unique part of MH and letting the user pick his preferred
326 set of other mail components.
327 Today's pre-packaged software components encourage this model.
328 Mmh is my way to provide this.
329 .P
330 It is worthwhile to fork nmh for the development of mmh,
331 because the two projects focus on different goals and differ in
332 fundamental questions.
333 The nmh community's reluctance regarding change conflicts
334 with my strong desire for it.
335 .[
336 nmh-workers schnalke understanding nmh
337 .]
338 In developing a separate experimental version, new approaches can
339 easily be tried out without the need to discuss changes beforehand.
340 In fact, revolutionary changes are hardly possible otherwise.
341 .P
342 The mmh project provides the basis on which the aforementioned
343 ideas can be implemented and demonstrated,
344 without the need to change the nmh project or its community.
345 Of course, the results of the mmh project shall improve nmh, in the end.
346 By no means it is my intent to work against the nmh project.
349 .U2 "Target Field
350 .P
351 Any effort needs to be targeted towards a specific goal
352 in order to be successful.
353 Therefore, a description of an imagined typical mmh user follows.
354 Actually, as mmh is my personal version of MH,
355 this is sort of a description of myself.
356 Developing software for one's own is a reliable way to produce software
357 that matches the user's desires.
358 .P
359 The target user of mmh likes Unix and its philosophy.
360 He appreciates to use programs that are conceptionally appealing.
361 He is familiar with the command line and enjoys its power.
362 He is capable of shell scripting and wants to improve his
363 productivity by scripting the mail system.
364 He uses modern email features, such as attachments,
365 non-ASCII text, digital signatures and message encryption in a natural way.
366 He is able to set up mail system components
367 and likes to pick the ones he prefers.
368 He has a reasonably modern operating system that complies to the
369 POSIX and ANSI C standards.
370 .P
371 The typical user invokes mmh commands directly in an interactive
372 shell session, even on workstations where graphical front-ends could
373 be added.
374 Likely, he runs his mail setup on a server machine,
375 to which he connects via ssh.
376 He might automate mail processing with mmh tools
377 but definitely he uses the tools to build better tools.
378 In any case, he wants to have the flexibility to change
379 his setup to suit his needs.
380 .P
381 The typical mmh user is a programmer.
382 He likes to, occasionally, make use of the opportunity of free software
383 by putting hands on and getting involved in software he uses.
384 In consequence, he likes small and clean code bases and cares for
385 code quality.
386 In general, he believes that:
387 .BU
388 The elegance of source code is most important.
389 .BU
390 Concepts are more important than concrete implementations.
391 .BU
392 Code optimizations for anything but readability should be avoided.
393 .BU
394 Removed code is debugged code.
395 .BU
396 Having a lot of choice is bad.
399 .U2 "Goals of the mmh Project
400 .IP "Streamlining
401 Mmh should be stripped down to its core, which is the user agent (MUA).
402 The feature set should be distilled to the indispensable ones,
403 effectively removing corner cases.
404 Parts that do not add to the main task of being a conceptionally
405 appealing user agent should be removed.
406 This includes the mail transfer and mail retrieval facilities.
407 Choice should be reduced to the main options.
408 All tools should be tightly shaped.
409 .IP "Modernizing
410 Mmh's feature set needs to become more modern.
411 Better support for attachments, digital signatures, and message
412 encryption should be added.
413 MIME support should be integrated deeper and more naturally.
414 The modern email features need to be readily available, out-of-the-box.
415 On the other hand, obsolete facilities can be dropped out and
416 ancient technologies need not be further supported.
417 The available concepts should be expanded as far as possible.
418 A small set of concepts should recur consistently.
419 .IP "Styling
420 Mmh's source code should be updated to modern standards.
421 Standardized library functions should replace non-standard versions
422 whenever possible.
423 Code should be separated into distinct modules when feasible.
424 Time and space optimizations should to be replaced by
425 clear and readable code.
426 A uniform programming style should prevail.
427 The whole system should appear to be of-one-style;
428 it should feel like being cast as one.