docs/master
view intro.roff @ 122:c234656329e0
Wrote about modularization.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Fri, 29 Jun 2012 22:51:25 +0200 |
| parents | 9f672d3a25f9 |
| children | 76c440261ebb |
line source
1 .RN 1
3 .H0 "Introduction
4 .P
5 MH is a set of mail handling tools with a common concept, similar to
6 the Unix tool chest, which is a set of file handling tools with a common
7 concept. \fInmh\fP is the currently most popular implementation of an
8 MH-like mail handling system.
9 This thesis describes an experimental version of nmh, named \fImmh\fP.
10 .P
11 This chapter introduces MH, its history, concepts and how it is used.
12 It describes nmh's code base and community to give the reader
13 a better understanding of the state of mmh when it started off.
14 Further more, this chapter outlines the mmh project itself,
15 describing the motivation for it and its goals.
18 .H1 "MH \(en the Mail Handler
19 .P
20 MH is a conceptual email system design and its concrete implementation.
21 Notably, MH had started as a design proposal at RAND Corporation,
22 where the first implementation followed later.
23 In spirit, MH is similar to Unix, which
24 influenced the world more in being a set of system design concepts
25 than in being a specific software product.
26 The ideas behind Unix are summarized in the \fIUnix philosophy\fP.
27 MH follows this philosophy.
29 .U2 "History
30 .P
31 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
32 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's existence, the concept was
38 believed to be practically unusable.
39 But the prototype proved successful and replaced MS thereafter.
40 In replacing MS, MH grew to an all-in-one mail system.
41 .P
42 In the early eighties,
43 the University of California at Irvine (UCI) started to use MH.
44 Marshall T. Rose and John L. Romine then became the driving force.
45 They took over the development and pushed MH forward.
46 RAND had put the code into the public domain by then.
47 MH was developed at UCI at the time when the Internet appeared,
48 when UCB implemented the TCP/IP stack, and when Allman wrote Sendmail.
49 MH was extended as emailing became more featured.
50 The development of MH was closely related to the development of email
51 RFCs. In the advent of MIME, MH was the first implementation of this new
52 email standard.
53 .P
54 In the nineties, the Internet became popular and in December 1996,
55 Richard Coleman initiated the ``New Mail Handler'' (nmh) project.
56 Nmh is a fork of MH 6.8.3 and bases strongly on the
57 \fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres.
58 Colman intended to modernize MH and improve its portability and
59 MIME handling capabilities.
60 This should be done openly within the Internet community.
61 The development of MH at UCI stopped after the 6.8.4 release in
62 February 1996, soon after the development of nmh had started.
63 Today, nmh has almost completely replaced the original MH.
64 Some systems might still provide old MH, but mainly for historical reasons.
65 .P
66 In the last years, the work on nmh was mostly maintenance work.
67 However, the development was revived in December 2011
68 and stayed busy since then.
70 .U2 "Concepts
71 .P
72 MH consists of a set of tools, each covering a specific task of
73 email handling, like composing a message, replying to a message,
74 refiling a message to a different folder, listing the messages in a folder.
75 All of the programs operate on a common mail storage.
76 .P
77 The mail storage consists of \fImail folders\fP (directories) and
78 \fPmessages\fP (regular files).
79 Each message is stored in a separate file in the format it was
80 received (i.e. transfer format).
81 The files are named with ascending numbers in each folder.
82 The specific format of the mail storage characterizes MH in the same way
83 as the format of the file system characterizes Unix.
84 .P
85 MH tools maintain a \fIcontext\fP, which includes the current mail folder.
86 Processes in Unix have a similar context, containing the current working
87 directory, for instance. In contrast, the process context is maintained
88 by the Unix kernel automatically, whereas MH tools need to maintain the MH
89 context themselves.
90 The user can have one MH context or multiple ones; he can even share it
91 with others.
92 .P
93 Messages are named by their numeric filename, but they can have symbolic names,
94 too. These are either automatically updated
95 position names such as the next or the last message,
96 or user-settable group names for arbitrary sets of messages.
97 These names are called sequences.
98 Sequences can be bound to the containing folder or to the context.
99 .P
100 The user's \fIprofile\fP is a file that contains his MH configuration.
101 Default switches for the individual tools can be specified to
102 adjust them to the user's personal preferences.
103 Multiple versions of the same command with different
104 default values can also be created very easily.
105 Form templates for new messages or for replies are easily changeable,
106 and output is adjustable with format files.
107 Almost every part of the system can be adjusted to personal preference.
108 .P
109 The system is well scriptable and extensible.
110 New MH tools are built out of or on top of existing ones quickly.
111 Further more, MH encourages the user to tailor, extend and automate the system.
112 As the MH tool chest was modeled after the Unix tool chest, the
113 properties of the latter apply to the former as well.
116 .ig \"XXX
118 .P
119 To ease typing, the switches can be abbreviated as much as the remaining
120 prefix remains unambiguous.
121 If in our example no other switch would start with the letter `t', then
122 .Cl "-truncate" ,
123 .Cl "-trunc" ,
124 .Cl "-tr" ,
125 and
126 .Cl "-t
127 would all be the same.
128 As a result, switches can neither be grouped (as in
129 .Cl "ls -ltr" )
130 nor can switch arguments be appended directly to the switch (as in
131 .Cl "sendmail -q30m" ).
132 .P
133 Many switches have negating counter-parts, which start with `no'.
134 For example
135 .Cl "-notruncate
136 inverts the
137 .Cl "-truncate
138 switch.
139 They exist to undo the effect of default switches in the profile.
140 If the user has chosen to change the default behavior of some tool
141 by adding a default switch to the profile,
142 he can still undo this change in behavior by specifying the inverse
143 switch on the command line.
145 ..
148 .U2 "Using MH
149 .P
150 It is strongly recommended to have a look at the MH Book,
151 which offers a thorough introduction to using MH.
152 .[ [
153 peek mh book
154 .], Part II]
155 Rose and Romine provide a deeper and more technical
156 though slightly outdated introduction in only about two dozens pages.
157 .[
158 rose romine real work
159 .]
160 .P
161 Following is an example mail handling session.
162 It uses mmh but is mostly compatible with nmh and old MH.
163 Details might vary but the look and feel is the same.
165 .VF input/mh-session
168 .H1 "nmh: Code and Community
169 .P
170 In order to understand the condition, goals and dynamics of a project,
171 one needs to know the reasons behind them.
172 This section explains the background.
173 .P
174 MH predates the Internet; it comes from times before networking was universal,
175 it comes from times when emailing was small, short and simple.
176 Then it grew, spread and adapted to the changes email went through.
177 Its core-concepts, however, remained the same.
178 During the eighties, students at UCI actively worked on MH.
179 They added new features and optimized the code for the then popular systems.
180 All this still was in times before POSIX and ANSI C.
181 As large parts of the code stem from this time, today's nmh source code
182 still contains many ancient parts.
183 BSD-specific code and constructs tailored for hardware of that time
184 are frequent.
185 .P
186 Nmh started about a decade after the POSIX and ANSI C standards were
187 established. A more modern coding style entered the code base, but still
188 a part of the developers came from ``the old days''. The developer
189 base became more diverse, thus broadening the range of different
190 coding styles.
191 Programming practices from different decades merged in the project.
192 As several peers added code, the system became more a conglomeration
193 of single tools rather than a homogeneous of-one-cast mail system.
194 Still, the existing basic concepts held it together.
195 They were mostly untouched throughout the years.
196 .P
197 Despite the separation of the tool chest approach at the surface
198 \(en a collection of small, separate programs \(en
199 on the source code level, it is much more interweaved.
200 Several separate components were compiled into one program
201 for efficiency reasons.
202 This led to intricate innards.
203 While clearly separated on the outside,
204 the programs turned out to be fairly interweaved inside.
205 .\" XXX FIXME rewrite...
206 .\" Unfortunately, the clear separation on the outside turned out to be
207 .\" fairly interweaved inside.
208 .P
209 The advent of MIME raised the complexity of email by a magnitude.
210 This is visible in nmh. The MIME-related parts are the most complex ones.
211 It is also visible that MIME support was added on top of the old MH core.
212 MH's tool chest style made this easily possible and encourages
213 such approaches, but unfortunately, it led to duplicated functions
214 and half-hearted implementation of the concepts.
215 .P
216 To provide backward-compatibility, it is a common understanding to not
217 change the default settings.
218 In consequence, the user needs to activate modern features explicitly
219 to be able to use them.
220 This puts a burden on new users, because out-of-the-box nmh remains
221 in the same ancient style.
222 If nmh is seen to be a back-end, then this compatibility surely is important.
223 However, in the same go, new users have difficulties using nmh for modern
224 emailing.
225 The small but mature community around nmh needs few change
226 as they have had their convenient setups for decades.
229 .H1 "mmh
230 .P
231 I started to work on my experimental version in October 2011,
232 at a time when there had been no more than three commits to nmh
233 since the beginning of the year.
234 In December, when I announced my work in progress on the
235 nmh-workers mailing list,
236 .[
237 nmh-workers mmh announce December
238 .]
239 nmh's community became active, too.
240 This movement was heavily pushed by Paul Vixie's ``edginess'' comment.
241 .[
242 nmh-workers vixie edginess
243 .]
244 After long years of stagnation, nmh became actively developed again.
245 Hence, while I was working on mmh, the community was once more working
246 on nmh, in parallel.
247 .P
248 The name \fImmh\fP may stand for \fImodern mail handler\fP,
249 because the project tries to modernize nmh.
250 Personally however, I prefer to call mmh \fImeillo's mail handler\fP,
251 emphasizing that the project follows my visions and preferences.
252 (My login name is \fImeillo\fP.)
253 This project model was inspired by \fIdwm\fP,
254 which is Anselm Garbe's personal window manager \(en
255 targeted to satisfy Garbe's personal needs whenever conflicts appear.
256 Dwm had retained its lean elegance and its focused character, whereas
257 its community-driven predecessor \fIwmii\fP had grown fat over time.
258 The development of mmh should remain focused.
261 .U2 "Motivation
262 .P
263 MH is the most important of very few command line tool chest email systems.
264 Tool chests are powerful because they can be perfectly automated and
265 extended. They allow arbitrary kinds of front-ends to be
266 implemented on top of them quickly and without internal knowledge.
267 Additionally, tool chests are easier to maintain than monolithic
268 programs.
269 As there are few tool chests for emailing and as MH-like ones are the most
270 popular among them, they should be developed further.
271 This keeps their
272 conceptional elegance and unique scripting qualities available to users.
273 Mmh creates a modern and convenient entry point to MH-like systems
274 for new and interested users.
275 .P
276 The mmh project is motivated by deficits of nmh and
277 my wish for general changes, combined
278 with the nmh community's reluctancy to change.
279 .P
280 At that time, nmh had not adjusted to modern emailing needs well enough.
281 The default setup was completely unusable for modern emailing.
282 Too much setup work was required.
283 Several modern features were already available but the community
284 did not want to have them as default.
285 Mmh is a way to change this.
286 .P
287 In my eyes, MH's concepts could be exploited even better and
288 the style of the tools could be improved. Both would simplify
289 and generalize the system, providing cleaner interfaces and more
290 software leverage at the same time.
291 Mmh is a way to demonstrate this.
292 .P
293 In providing several parts of an email system, nmh can hardly
294 compete with the large specialized projects that focus
295 on only one of the components.
296 The situation can be improved by concentrating the development power
297 on the most unique part of MH and letting the user pick his preferred
298 set of other mail components.
299 Today's pre-packaged software components encourage this model.
300 Mmh is a way to go for this approach.
301 .P
302 It is worthwhile to fork nmh for the development of mmh, because
303 the two projects focus on different goals and differ in fundamental questions.
304 The nmh community's reluctance regarding change conflicts
305 with my strong desire for it.
306 In developing a separate experimental version new approaches can
307 easily be tried out without the need to discuss changes beforehand.
308 In fact, revolutionary changes are hardly possible otherwise.
309 .P
310 The mmh project provides the basis on which the aforementioned
311 ideas can be implemented and demonstrated,
312 without the need to change nmh or its community.
313 Of course, the results of the mmh project shall improve nmh, in the end.
314 By no means is my intend to work against the nmh project.
317 .U2 "Target Field
318 .P
319 Any effort needs to be targeted towards a specific goal
320 in order to be successful.
321 Following is a description of imagined typical mmh users.
322 Mmh should satisfy their needs.
323 .\" XXX Remove the next sentence?
324 Actually, as mmh is my personal version of MH, this is a description
325 of myself.
326 .P
327 The target users of mmh like Unix and its philosophy.
328 They appreciate to use programs that are conceptionally appealing.
329 They are familiar with the command line and enjoy its power.
330 They are at least capable of shell scripting and want to improve their
331 productivity by scripting the mail system.
332 .\" XXX Naturally, he uses ...
333 They naturally use modern email features, such as attachments,
334 non-ASCII text, and digital cryptography.
335 They are able to setup email system components besides mmh,
336 and actually like to have the choice to pick the ones they prefer.
337 They have a reasonably modern operating system that complies to standards,
338 like POSIX and ANSI C.
339 .P
340 The typical users invoke mmh commands directly in an interactive
341 shell session, but they use them to automate mail handling tasks as well.
342 Likely, they runs their mail setup on a server machine,
343 to which they connect via ssh.
344 They might also have local mmh installations on their workstations,
345 where they tend to work with mmh directly in the shell instead
346 of using graphical front-ends.
347 They definitely want to be flexible and thus be able to change
348 their setup to suit their needs.
349 .P
350 .\" XXX themself vs. themselves
351 Typical mmh users are programmers themselves.
352 They like to, occasionally, take the opportunity of Free Software to put
353 hands on and get involved in the software they use.
354 Hence, they like small and clean code bases and care for code quality.
355 In general, they believe that:
356 .BU
357 Elegance \(en i.e. simplicity, clarity and generality \(en
358 is most important.
359 .BU
360 Concepts are more important than the concrete implementation.
361 .BU
362 Code optimizations for anything but readability should be avoided
363 if possible.
364 .BU
365 Having a lot of choice is bad.
366 .BU
367 Removed code is debugged code.
369 .U2 "Goals
370 .P
371 The general goals for the mmh project are the following:
372 .IP "Stream-lining
373 Mmh should be stripped down to its core, which is the user agent (MUA).
374 The feature set should be distilled to the indispensable ones,
375 effectively removing corner-cases.
376 Parts that don't add to the main task of being a conceptionally
377 appealing MUA should be removed.
378 This includes the mail submission and mail retrieval facilities.
379 Choice should be reduced to the main options.
380 .IP "Modernizing
381 Mmh's feature set needs to become more modern.
382 Better support for attachment and digital cryptography should be added.
383 MIME support should to be integrated deeper and more naturally.
384 The modern email features need to be readily available, out-of-the-box.
385 On the other hand,
386 bulletin board support and similar obsolete facilities can be dropped out.
387 Likewise, ancient technologies such as hardcopy terminals
388 need not to be supported any further.
389 .IP "Code style
390 Mmh's source code needs to be updated to modern standards.
391 Standardized library functions should replace non-standard versions
392 whenever possible.
393 Code should be separated into distinct modules when feasible.
394 Time and space optimizations should to be replaced by
395 clear and readable code.
396 A uniform programming style should prevail.
397 .IP "Homogeneity
398 The available concepts need to be expanded as far as possible.
399 A small set of concepts should recur consistently.
400 The whole system should appear to be of-one-style;
401 it should feel like being cast as one.