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