docs/master
view ch01.roff @ 47:eae5e50381ce
Rework in Preface and Intro.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Fri, 18 May 2012 11:21:51 +0200 |
| parents | 7a33b5adb672 |
| children | d28ff07dfc0f d3a02f5e63b3 |
line source
1 .RN 1
3 .H0 "Introduction
4 .P
5 This chapter introduces MH, its history, concepts and how it is used.
6 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 outlines the mmh project itself,
9 describing the motivation for it and its goals.
12 .H1 "MH \(en the Mail Handler
13 .P
14 MH is a conceptual email system design and its concrete implementation.
15 Notably, MH had started as a design proposal at RAND Corporation,
16 where the first implementation followed later.
17 In spirit, MH is similar to Unix, which
18 influenced the world more in being a set of system design concepts
19 than in being a specific software product.
20 The ideas behind Unix are summarized in the \fIUnix philosophy\fP.
21 MH follows this philosophy.
23 .U2 "History
24 .P
25 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
26 had proposed the design
27 of a new mail handling system, called ``Mail Handler'' (MH),
28 to superseed RAND's old monolithic ``Mail System'' (MS).
29 Two years later, in 1979, Bruce Borden took the proposal and implemented a
30 prototype of MH.
31 Before the prototype had been available, the concept was
32 believed to be practically unusable.
33 But the prototype had proven successful and replaced MS thereafter.
34 In replacing MS, MH grew to an all-in-one mail system.
35 .P
36 In the early Eighties,
37 the University of California at Irvine (UCI) had started to use MH.
38 They also took over its development and pushed MH forward.
39 Marshall T. Rose and John L. Romine became the driving force then.
40 This was the time when the Internet appeared, when UCB implemented
41 the TCP/IP stack, and when Allman wrote Sendmail.
42 MH was extended as emailing became more featured.
43 The development of MH was closely related to the development of email
44 RFCs. In the advent of MIME, MH was the first implementation of this new
45 email standard.
46 .P
47 In the Nineties, MH had been moved into the public domain, making it
48 attractive to Free Software developers.
49 The Internet had became popular and in December 1996,
50 Richard Coleman initiated the ``New Mail Handler'' (nmh) project.
51 The project is a fork of MH 6.8.3 and bases strongly on the
52 \fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres.
53 Colman intended to modernize MH and improve its portability and
54 MIME handling capabilities.
55 This should be done openly within the Internet community.
56 The development of MH at UCI stopped after the 6.8.4 release in
57 February 1996, soon after the development of nmh had started.
58 Today, nmh almost completely replaced the original MH.
59 Some systems might still provide old MH, but mainly for historical reasons.
60 .P
61 In the last years, the work on nmh was mostly maintenance work.
62 However, the development revived in December 2011 and stayed busy since then.
64 .U2 "Concepts
65 .P
66 MH is a toolchest, modelled after the Unix toolchest. It consists of a
67 set of tools, each covering a specific task of email handling, like
68 composing a message, replying to a message, refiling a message to a
69 different folder, listing the messages in a folder.
70 All of the programs operate on a common mail storage.
71 .P
72 The mail storage consists of \fImail folders\fP (directories) and
73 \fPmessages\fP (regular files).
74 Each message is stored in a separate file in the format it had been
75 received (i.e. transfer format).
76 The files are named with ascending numbers in each folder.
77 The specific format of the mail storage characterizes MH in the same way
78 like the format of the file system characterizes Unix.
79 .P
80 MH tools maintain a \fIcontext\fP, which includes the current mail folder.
81 Processes in Unix have a similar context, containing the current working
82 directory, for instance. In contrast, the process context is maintained
83 by the Unix kernel automatically, whereas MH tools need to maintain the MH
84 context themselves.
85 The user can have one MH context or multiple ones, he can even share it
86 with other users.
87 .P
88 Messages are named by their numeric filename, but they can have symbolic names,
89 too. These are either automatically updated
90 position names like being the next or the last message,
91 or user-settable group names for arbitrary sets of messages.
92 These names are called sequences.
93 Sequences can be bound to the containing folder or to the context.
94 .P
95 The user's \fIprofile\fP is a file that contains his MH configuration.
96 Default switches for the individual tools can be specified to
97 adjust them to the user's personal preferences.
98 Multiple versions of the same command with different
99 default values can also be created very easily.
100 Form templates for new messages or for replies are easily changable,
101 and output is adjustable with format files.
102 Almost every part of the system can be adjusted to personal preference.
103 .P
104 The system is well scriptable and extendable.
105 New MH tools are built out of or on top of existing ones quickly.
106 Further more, MH encourages the user to taylor, extend and automate the system.
107 As the MH toolchest was modelled after the Unix toolchest, the
108 properties of the latter apply to the former as well.
111 .U2 "Example Session
112 .P
113 Following is an example mail handling session with mmh.
114 It should be mostly compatible with nmh and old MH.
115 Details might vary but the look'n'feel is the same.
116 .DS
117 $ \f(CBinc\fP
118 Incorporating new mail into inbox...
120 1+ 2012-05-16 11:16 meillo@dream.home Hello
121 2 2012-05-16 11:17 meillo@dream.home book
123 $ \f(CBshow\fP
124 Date: Wed, 16 May 2012 11:16:00 +0200
125 To: meillo
126 From: <meillo@dream.home.schnalke.org>
127 Subject: Hello
129 part text/plain 13
130 mmh is great
132 $ \f(CBnext\fP
133 Date: Wed, 16 May 2012 11:17:24 +0200
134 To: meillo
135 From: <meillo@dream.home.schnalke.org>
136 Subject: book
138 part text/plain 79
139 Hello meillo,
141 have a look at the ``Daemon book''. You need to read that!
143 foo
145 $ \f(CBrmm 1\fP
147 $ \f(CBscan\fP
148 2+ 2012-05-16 11:17 meillo@dream.home book
150 $
151 .DE
154 .H1 "nmh: Code and Community
155 .P
156 In order to understand the state, goals and dynamics of a project,
157 one needs to know its history. MH predates the Internet,
158 it comes from times before networking was universal,
159 times when emailing was small, short and simple.
160 Then it grew, spread and adopted to the changes email went through.
161 The core-concepts, however, remained the same.
162 During the 80s a small group of students at the University of
163 California, actively worked on MH. They added features and optimized,
164 like it is common for scientific work. This is still in pre-ANSI C
165 times. The source code contains many ancient parts. Code constructs
166 specific to BSD or hardware of that time are usual.
167 .P
168 Nmh started eight years after the ANSI C standard had been
169 established. A more modern coding style entered the code base. Still
170 a part of the developers come from ``the old days''. The developer
171 base became more diverse and thus the code had different style.
172 Programming practices
173 from different decades merged into the project. Different coding
174 styles came together. It appears as if multiple peers added code
175 parts, resulting in a conclomeration rather than a homogenic
176 of-one-cast mail system. Still, the basic concepts hold it together.
177 They were mostly untouched throughout the years.
178 .P
179 Although, at the surface, nmh is a toolchest, meaning a collection
180 of completely modularized small programs, on the source code level,
181 it is much more interweaved. Parts of the basic functions are
182 collected in a MH standard library, which is good, but often
183 separate functions are compiled into programs, for effiency reasons.
184 This lead to intricate innards.
185 The advent of MIME rose the complexity of email by a magnitude. This
186 is visible in nmh. The MIME-related parts are the most complex ones.
187 It's also visible that MIME support had been added on top of the
188 old MH later. The MH style made this easily possible, but it
189 also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
190 and had not been thoroughly included into the concepts (e.g. the
191 user-visible access to whole messages and MIME parts are inherently
192 different).
193 .P
194 For backward-compatibility's sake, it is a common understanding to have the
195 default settings to be compatible, requiring any new feature to be
196 explicitely enabled.
197 In consequence, the user needs to activate modern features explicitely
198 to be able to use them.
199 This puts a burden on new users, because nmh
200 out-of-the-box keeps staying in the same ancient style, where users
201 usually want to have it practical for modern emailing.
202 But of course, this depends if nmh is seen to be a front-end or a
203 back-end.
206 .H1 "mmh
207 .P
208 I started to work on my experimental version in Fall 2011.
209 In December, when I announced my work on the nmh-workers mailing list,
210 .[
211 nmh-workers mmh announce december
212 .]
213 the activity in nmh rose heavily.
214 Suddently the community started to move.
215 This movement was pushed much by Paul Vixie's ``edginess'' message.
216 .[
217 nmh-workers vixie edginess
218 .]
219 After long years of much stagnation, nmh became actively developed again.
220 Hence, while I was working on mmh, the community was working on nmh,
221 in parallel.
222 .P
223 The name \fImmh\fP stands for \fImeillo's mail handler\fP,
224 because mmh is my own version of MH.
225 (My login name is \fImeillo\fP.)
226 The project follows my personal considerations and preferences.
227 By calling it a personal project, I don't need to justify my decisions,
228 though, still I do.
229 This enabled me to follow my vision staightly and thus produce
230 a result of greater pureness.
231 This project model was inspired by the window manager \fIdwm\fP,
232 which is Anselm Garbe's personal window manager \(en
233 targeted to satisfy Garbe's personal needs whenever conflicts appear.
234 dwm had remained much more focused on its original goals,
235 whereas its community-driven predecessor \fIwmii\fP had
236 grown large and lost it's leanness.
237 This should not happen to mmh.
238 .P
239 Mmh can also stand for \fImodern mail handler\fP, and this is
240 the variant chosen as titel for this document. One main focus of the
241 project was to modernize nmh. Another main goal is resembled in the
242 name \fIminimized mail handler\fP: Drop any parts that don't add
243 to the main task of mmh, being a MUA.
244 .P
245 It should also be noted that \fLstrcmp("mmh","nmh")<0\fP is true.
246 Although mmh bases on nmh, it is likely seen as a step backward.
247 I agree.
248 However, this step backward actually is a step forward,
249 although in another direction.
252 .H1 "This Thesis
254 .U2 "Motivation
255 .P
256 MH is the most important of very few command line toolchest email systems.
257 (There's also \fIim\fP by Tatsuya Kinoshita,
258 which operates on an MH mail storage.)
259 Toolchests are powerful because they can be perfectly automated and
260 extended. Toolchests are good back-ends for various sorts of front-ends.
261 They allow multiple front-ends for different special needs
262 to be implemented quickly and withough internal knowledge on emailing.
263 Further more, toolchests are much better to maintain than large monolithic
264 programs.
265 As there are few toolchests for emailing and MH-like ones are the most
266 popular amoung them, they should be developed further to keep their
267 conceptional elegance and unique scripting qualities available to users.
268 mmh will create a modern and convenient entry point for new, interested
269 users to MH-like systems.
270 .P
271 The mmh project is motivated by deficites of nmh and
272 my wish for general changes, combined
273 with the nmh community's reluctancy to change.
274 .P
275 nmh hadn't adjusted to modern emailing needs well enough.
276 The default setup was completely unusable for modern emailing.
277 Too much setup work was required.
278 Several modern features were already available but the community
279 didn't wanted to have them as default.
280 mmh is a way to change this.
281 .P
282 In my eyes, MH's concepts could be exploited even better and
283 the style of the tools could be improved. Both would simplify
284 and generalize the system, providing cleaner interfaces and more
285 software leverage, at the same time.
286 mmh is a way to demonstrate this.
287 .P
288 In providing several parts of an email system, nmh can hardly
289 compete with the large specialized projects that focus
290 on only one of the components.
291 The situation can be improved by concentrating the development power
292 on the most unique part of MH and letting the user pick his prefered
293 set of other mail components.
294 Today's pre-packaged software components encourage this model.
295 mmh is a way to go for this approach.
296 .P
297 It's worthwhile to fork nmh for the development of mmh, because
298 the two projects focus on different goals and differ in fundamental questions.
299 The nmh community's reluctance to change conflicts
300 with my strong will to change.
301 In developing a separate experimental version new approaches can
302 easily be tried out without the need to discuss changes beforehand.
303 In fact, revolutionary changes are hardly possible otherwise.
304 These reasons support the decision to start mmh as a fork of nmh.
305 .P
306 The mmh project provides the basis to implemented and demonstrated
307 the listed ideas without the need to change nmh or its community.
308 Of course, the results of the mmh project shall improve nmh, in the end.
310 .U2 "Target Field
311 .P
312 Any effort needs to be targeted towards a specific goal
313 in order to be successful.
314 Following is a description of the imagined typical mmh user.
315 mmh should satisfy his needs.
316 .P
317 The target user of mmh likes Unix and its philosophy.
318 He likes to use programs that are conceptionally appealing.
319 He's familiar with the command line and enjoys its power.
320 He is at least capable of shell scripting and wants to improve his
321 productivity by scripting the mail system.
322 He naturally uses modern email features, like attachments,
323 non-ASCII text, and digital cryptrography.
324 He is able to setup email system components besides mmh,
325 and actually likes the choice to pick the ones he preferes.
326 He has a reasonably modern system that complies to standards,
327 like POSIX and ANSI C.
328 .P
329 XXX common scenarios?
330 .P
331 General assumptions of the project are:
332 .BU
333 Elegance \(en being simplicity, clarity and generality \(en is most important.
334 .BU
335 Concepts are more important than concrete implementations.
336 .BU
337 Time and space optimizations are only useful if absolutely needed to make
338 the software usable.
339 .BU
340 Having a lot of choice is bad.
342 .U2 "Work to do
343 .P
344 The general goals for the mmh project are the following:
345 .BU
346 mmh should be perfectly suited for modern emailing, out-of-the-box.
347 This is a necessity to spread among new users.
348 .BU
349 The system shall be of-one-style. It should feel like cast as one.
350 .P
351 To do list:
352 .BU
353 Remove the MTA and MRA facilities. Mmh shall concentrate on the MUA
354 task. Mail shall enter mmh's mail storage via the system mail drop
355 and it shall leave mmh via the local \fLsendmail\fP command.
356 .BU
357 Remove any further functions that are not related to mmh's main task.
358 Bulletin board support is on example. Also remove support for ancient
359 technologies, like hardcopy terminals.
360 .BU
361 Refactor the source code to meet modern style criteria. Use
362 standardized library functions when possible.
363 .BU
364 Replace performance optimizations by clear and readable code.
365 .BU
366 Reduce the feature set to the commonly used one, removing
367 corner-cases. Set sane default values.
368 .BU
369 Add better attachment support. Add support for digital signatures and
370 encryption.
371 .BU
372 Merge \fLshow\fP and \fLmhshow\fP into one single mail display program.
373 Integrate MIME support deeper and more natural into MH.
374 .BU
375 Provide a ready-to-use setup out-of-the-box.
377 .U2 "Methods
378 .P
379 foo