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