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