docs/master
view ch01.roff @ 51:49cf68506b5d
Spell checking.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Sun, 20 May 2012 11:40:19 +0200 |
| parents | a446f89cc5d9 |
| children | 01d06ca2eb1b |
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 tool chest, modeled after the Unix tool chest. 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 changeable,
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 extensible.
105 New MH tools are built out of or on top of existing ones quickly.
106 Further more, MH encourages the user to tailor, extend and automate the system.
107 As the MH tool chest was modeled after the Unix tool chest, 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 condition, goals and dynamics of a project,
157 one needs to know the reasons.
158 MH predates the Internet, it comes from times before networking was universal,
159 it comes from times when emailing was small, short and simple.
160 Then it grew, spread and adopted to the changes email went through.
161 Its core-concepts, however, remained the same.
162 During the Eighties students at UCI actively worked on MH.
163 They added new features and optimized the code for the then popular systems.
164 All this still was in times before POSIX and ANSI C.
165 As large parts of the code stem from this time, today's nmh source code
166 still contains many ancient parts.
167 BSD-specific code and constructs tailored for hardware of that time
168 are frequent.
169 .P
170 Nmh started about a decade after the POSIX and ANSI C standards had been
171 established. A more modern coding style entered the code base, but still
172 a part of the developers came from ``the old days''. The developer
173 base became more diverse and thus resulted in code of different style.
174 Programming practices from different decades merged in the project.
175 As several peers added code, the system became more a conglomeration
176 of single tools rather than a homogeneous of-one-cast mail system.
177 Still, the existing basic concepts held it together.
178 They were mostly untouched throughout the years.
179 .P
180 Despite the tool chest approach at the surface \(en a collection
181 of separate small programs \(en on the source code level
182 it is much more interweaved.
183 Several separate components were compiled into one program
184 for efficiency reasons.
185 This lead to intricate innards.
186 Unfortunately, the clear separation on the outside appeared as being
187 pretty interweaved inside.
188 .P
189 The advent of MIME rose the complexity of email by a magnitude.
190 This is visible in nmh. The MIME-related parts are the most complex ones.
191 It's also visible that MIME support had been added on top of the old MH core.
192 MH's tool chest style made this easily possible and encourages
193 such approaches, but unfortunately, it lead to duplicated functions
194 and half-hearted implementation of the concepts.
195 .P
196 To provide backward-compatibility, it is a common understanding to not
197 change the default settings.
198 In consequence, the user needs to activate modern features explicitly
199 to be able to use them.
200 This puts a burden on new users, because out-of-the-box nmh remains
201 in the same ancient style.
202 If nmh is seen to be a back-end, then this compatibility surely is important.
203 However, in the same go, new users have difficulties to use nmh for modern
204 emailing.
205 The small but matured community around nmh hardly needs much change
206 as they have their convenient setups since decades.
209 .H1 "mmh
210 .P
211 I started to work on my experimental version in October 2011,
212 when there were no more than three commits to nmh in the previous nine months..
213 In December, when I announced my work on the nmh-workers mailing list,
214 .[
215 nmh-workers mmh announce December
216 .]
217 the activity in nmh rose much.
218 Suddenly, the community started to move.
219 This movement was heavily pushed by Paul Vixie's ``edginess'' comment.
220 .[
221 nmh-workers vixie edginess
222 .]
223 After long years of much stagnation, nmh became actively developed again.
224 Hence, while I was working on mmh, the community was working on nmh,
225 in parallel.
226 .P
227 The name \fImmh\fP stands for \fImeillo's mail handler\fP,
228 because mmh is my own version of MH.
229 (My login name is \fImeillo\fP.)
230 The project follows my personal considerations and preferences.
231 By calling it a personal project, I don't need to justify my decisions,
232 though, still I like to do.
233 This enabled me to follow my vision straightly and thus produce
234 a result of greater pureness.
235 This project model was inspired by the window manager \fIdwm\fP,
236 which is Anselm Garbe's personal window manager \(en
237 targeted to satisfy Garbe's personal needs whenever conflicts appear.
238 dwm had remained much more focused on its original goals,
239 whereas its community-driven predecessor \fIwmii\fP had
240 grown big and lost it's lean elegance.
241 This should not happen to mmh.
242 .P
243 Mmh also stands for \fImodern mail handler\fP, and this is
244 the variant chosen to entitle this document. One main focus of the
245 project was to modernize nmh. Another main goal is resembled in the
246 name \fIminimized mail handler\fP: Drop any parts that don't add
247 to the main task of mmh, being a conceptionally appealing MUA.
248 .P
249 It should also be noted that \fLstrcmp("mmh","nmh")<0\fP is true.
250 Although mmh bases on nmh, it is likely seen as a step backward.
251 I agree.
252 However, this step backward actually is a step forward,
253 although in a different direction.
256 .H1 "This Thesis
258 .U2 "Motivation
259 .P
260 MH is the most important of very few command line tool chest email systems.
261 (There's also \fIim\fP by Tatsuya Kinoshita,
262 which operates on an MH mail storage.)
263 Tool chests are powerful because they can be perfectly automated and
264 extended. Tool chests are good back-ends for various sorts of front-ends.
265 They allow multiple front-ends for different special needs
266 to be implemented quickly and without internal knowledge on emailing.
267 Further more, tool chests are much better to maintain than large monolithic
268 programs.
269 As there are few tool chests for emailing and MH-like ones are the most
270 popular among them, they should be developed further to keep their
271 conceptional elegance and unique scripting qualities available to users.
272 mmh will create a modern and convenient entry point for new, interested
273 users to MH-like systems.
274 .P
275 The mmh project is motivated by deficits of nmh and
276 my wish for general changes, combined
277 with the nmh community's reluctancy to change.
278 .P
279 nmh hadn't adjusted to modern emailing needs well enough.
280 The default setup was completely unusable for modern emailing.
281 Too much setup work was required.
282 Several modern features were already available but the community
283 didn't wanted to have them as default.
284 mmh is a way to change this.
285 .P
286 In my eyes, MH's concepts could be exploited even better and
287 the style of the tools could be improved. Both would simplify
288 and generalize the system, providing cleaner interfaces and more
289 software leverage, at the same time.
290 mmh is a way to demonstrate this.
291 .P
292 In providing several parts of an email system, nmh can hardly
293 compete with the large specialized projects that focus
294 on only one of the components.
295 The situation can be improved by concentrating the development power
296 on the most unique part of MH and letting the user pick his preferred
297 set of other mail components.
298 Today's pre-packaged software components encourage this model.
299 mmh is a way to go for this approach.
300 .P
301 It's worthwhile to fork nmh for the development of mmh, because
302 the two projects focus on different goals and differ in fundamental questions.
303 The nmh community's reluctance to change conflicts
304 with my strong will to change.
305 In developing a separate experimental version new approaches can
306 easily be tried out without the need to discuss changes beforehand.
307 In fact, revolutionary changes are hardly possible otherwise.
308 These reasons support the decision to start mmh as a fork of nmh.
309 .P
310 The mmh project provides the basis to implemented and demonstrated
311 the listed ideas without the need to change nmh or its community.
312 Of course, the results of the mmh project shall improve nmh, in the end.
314 .U2 "Target Field
315 .P
316 Any effort needs to be targeted towards a specific goal
317 in order to be successful.
318 Following is a description of the imagined typical mmh user.
319 mmh should satisfy his needs.
320 Actually, as mmh is my personal version of MH, this is a description
321 of myself.
322 .P
323 The target user of mmh likes Unix and its philosophy.
324 He likes to use programs that are conceptionally appealing.
325 He's familiar with the command line and enjoys its power.
326 He is at least capable of shell scripting and wants to improve his
327 productivity by scripting the mail system.
328 He naturally uses modern email features, like attachments,
329 non-ASCII text, and digital cryptography.
330 He is able to setup email system components besides mmh,
331 and actually likes the choice to pick the ones he prefers.
332 He has a reasonably modern system that complies to standards,
333 like POSIX and ANSI C.
334 .P
335 The typical user invokes mmh commands directly in an interactive
336 shell session, but as well, he uses them to automate mail handling tasks.
337 Likely, he runs his mail setup on a server machine, to which he connects
338 via ssh. He might also have local mmh installations on his workstations,
339 but does rather not rely on graphical front-ends. He definitely wants
340 to be flexible and thus be able to change his setup to suite his needs.
341 .P
342 The typical mmh user is a programmer himself.
343 He likes to, occasionally, take the opportunity of Free Software to put
344 hands on and get involved in the software he uses.
345 Hence, he likes small and clean code bases and he cares for code quality.
346 In general, he believes that:
347 .BU
348 Elegance \(en i.e. simplicity, clarity and generality \(en
349 is most important.
350 .BU
351 Concepts are more important than the concrete implementation.
352 .BU
353 Code optimizations for anything but readability should be avoided
354 if possible.
355 .BU
356 Having a lot of choice is bad.
357 .BU
358 Removed code is debugged code.
360 .U2 "Goals
361 .P
362 The general goals for the mmh project are the following:
363 .IP "Stream-lining
364 Mmh should be stripped down to its core, which is the MUA part of emailing.
365 The feature set should be distilled to the ones really needed,
366 effectively removing corner-cases.
367 Functions that are not related to the main task should be removed.
368 This includes, the MTA and MRA facilities.
369 Choice should be reduced to the main options.
370 .IP "Modernizing
371 Mmh's feature set needs to become more modern.
372 Better support for attachment and digital cryptography needs to be added.
373 MIME support needs to be integrated deeper and more naturally.
374 The modern email features need to be readily available, out-of-the-box.
375 And on the other hand,
376 bulletin board support and similar obsolete facilities need to be dropped
377 out.
378 Likewise, ancient technologies, like hardcopy terminals, should not
379 be supported any further.
380 .IP "Code style
381 Mmh's source code needs to be updated to modern standards.
382 Standardized library functions should replace non-standard versions
383 whenever possible.
384 Code should be separated into distinct modules when possible.
385 Time and space optimizations should to be replaced by
386 clear and readable code.
387 A uniform programming style should prevail.
388 .IP "Homogeneity
389 The available concepts need to be expanded as far as possible.
390 A small set of concepts should prevail thoroughly throughout the system.
391 The whole system should appear to be of-one-style.
392 It should feel like being cast as one.