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