| rev |
line source |
|
meillo@0
|
1 .H0 "Preface" no
|
|
meillo@0
|
2
|
|
meillo@23
|
3 .P
|
|
meillo@171
|
4 I have discovered the mail client \fInmh\fP in fall 2009.
|
|
meillo@87
|
5 At that time I used \fImutt\fP, as many advanced Unix users do.
|
|
meillo@87
|
6 When I read about nmh, its concepts convinced me at once.
|
|
meillo@87
|
7 The transition from mutt to nmh was similar to beginning with
|
|
meillo@87
|
8 file management in the Unix shell when being used to the
|
|
meillo@53
|
9 \fImidnight commander\fP,
|
|
meillo@87
|
10 or like starting with vi when being used to modeless editors.
|
|
meillo@87
|
11 Such a change is not trivial, but, in being convinced by the
|
|
meillo@31
|
12 concepts and by having done similar transitions for file management
|
|
meillo@53
|
13 and editing already, it was not too difficult.
|
|
meillo@51
|
14 In contrast, setting up nmh to a convenient state became a tedious task
|
|
meillo@23
|
15 that took several months.
|
|
meillo@164
|
16 Once having nmh arranged this way, I enjoyed using it
|
|
meillo@28
|
17 because of its conceptional elegance and its scripting capabilities.
|
|
meillo@106
|
18 Nevertheless, it was still inconvenient for handling attachments,
|
|
meillo@87
|
19 non-ASCII character encodings, and similar features of modern emailing.
|
|
meillo@31
|
20 My setup demanded more and more additional configuration and helper scripts
|
|
meillo@87
|
21 to have nmh behave the way I wanted; yet my
|
|
meillo@31
|
22 expectations were rather common for modern emailing.
|
|
meillo@106
|
23 As a computer scientist and programmer, I wanted to improve the situation.
|
|
meillo@8
|
24 .P
|
|
meillo@171
|
25 In spring 2010, I sent a message to the \fInmh-workers\fP mailing list,
|
|
meillo@106
|
26 asking for the possibility to offer a Google Summer of Code project for me.
|
|
meillo@106
|
27 Participating in the development of nmh in this manner appeared attractive
|
|
meillo@106
|
28 to me, because I would have been able to work full time on nmh.
|
|
meillo@106
|
29 Although the nmh community had reacted generally positive to the suggestion,
|
|
meillo@171
|
30 the administrative work for such a project would had been too much.
|
|
meillo@106
|
31 Nonetheless, my proposal had activated the nmh community.
|
|
meillo@31
|
32 In the following weeks, goals for nmh's future were discussed.
|
|
meillo@31
|
33 In these discussions, I became involved in the
|
|
meillo@53
|
34 question whether nmh should include mail transfer facilities.
|
|
meillo@34
|
35 .[
|
|
meillo@34
|
36 nmh-workers thread mta mua
|
|
meillo@34
|
37 .]
|
|
meillo@87
|
38 I argued for the MTA of nmh to be removed.
|
|
meillo@87
|
39 In this fundamental question,
|
|
meillo@87
|
40 my opinion differed from the opinion of most others.
|
|
meillo@87
|
41 Sadly, besides the discussions, hardly any real work was done.
|
|
meillo@87
|
42 Being unable to work on nmh in a way that would be accepted at university
|
|
meillo@87
|
43 as part of my studies, I needed to choose another project.
|
|
meillo@8
|
44 .P
|
|
meillo@23
|
45 Half a year later, starting in August 2010,
|
|
meillo@23
|
46 I took one semester off to travel through Latin America.
|
|
meillo@87
|
47 During my time in Argentina, I wanted to work on Free Software.
|
|
meillo@23
|
48 This brought me back to nmh.
|
|
meillo@159
|
49 Richard Sandelman, an active nmh user, took care of the official basis.
|
|
meillo@106
|
50 Juan Granda, an Argentine Free Software developer,
|
|
meillo@87
|
51 provided a computer with Internet connection.
|
|
meillo@53
|
52 Thanks to them, I was able to work on nmh during my three-month
|
|
meillo@87
|
53 stay in Santiago del Estero, Argentina.
|
|
meillo@106
|
54 Quickly it became obvious that I would not succeed with my main goal,
|
|
meillo@87
|
55 to improve the character encoding handling.
|
|
meillo@87
|
56 (One of its ramifications is the
|
|
meillo@87
|
57 missing transfer decoding of quoted text in replies.)
|
|
meillo@23
|
58 As this is one of the most intricate parts of the system, the goal
|
|
meillo@53
|
59 was simply set too high.
|
|
meillo@53
|
60 Instead, I improved the code base as I read through it.
|
|
meillo@87
|
61 I found minor bugs for which I proposed fixes.
|
|
meillo@171
|
62 Additionally, I improved the documentation in minor ways.
|
|
meillo@53
|
63 When I started with larger code changes,
|
|
meillo@53
|
64 I had to discover that the community was reluctant to change.
|
|
meillo@53
|
65 Its wish for compatibility was much stronger than its
|
|
meillo@31
|
66 wish for convenient out-of-the-box setups \(en in contrast to my opinion.
|
|
meillo@106
|
67 This, once again, led to long discussions.
|
|
meillo@53
|
68 I came to understand their point of view, but it was different to mine.
|
|
meillo@23
|
69 At the end of my three-month project, I had become familiar with
|
|
meillo@87
|
70 nmh's code base and community,
|
|
meillo@53
|
71 I had improved the project in minor ways,
|
|
meillo@87
|
72 and I still was convinced that I wanted to continue to do so.
|
|
meillo@23
|
73 .P
|
|
meillo@53
|
74 Another half year later, the end of my studies came within reach.
|
|
meillo@23
|
75 I needed a topic for my master's thesis.
|
|
meillo@106
|
76 Without question, I wanted to work on nmh.
|
|
meillo@106
|
77 But not exactly on nmh, because I had accepted that its
|
|
meillo@106
|
78 community has different goals than I have.
|
|
meillo@87
|
79 Working on nmh would result in much discussion and, in consequence,
|
|
meillo@87
|
80 little progress.
|
|
meillo@23
|
81 After careful thought, I decided to start an experimental version of nmh.
|
|
meillo@31
|
82 I wanted to implement my own ideas of how an MH-like system should look like.
|
|
meillo@31
|
83 I wanted to create a usable alternative version to be compared with
|
|
meillo@31
|
84 the present state of nmh.
|
|
meillo@53
|
85 Eventually, my work would be proven successful or not.
|
|
meillo@53
|
86 In any case, the nmh project would profit from my experiences.
|
|
meillo@28
|
87
|
|
meillo@30
|
88 .U2 "Focus of this Document
|
|
meillo@8
|
89 .P
|
|
meillo@53
|
90 This document explains the design goals and implementation decisions
|
|
meillo@53
|
91 for mmh.
|
|
meillo@171
|
92 .\" XXX mmh taucht hier zum ersten mal auf.
|
|
meillo@31
|
93 It discusses technical, historical, social and philosophical considerations.
|
|
meillo@31
|
94 On the technical side, this document
|
|
meillo@125
|
95 explains how an existing project was streamlined by removing rough edges
|
|
meillo@106
|
96 and better exploitation of the central concepts.
|
|
meillo@106
|
97 On the historical side, changes through time are discussed,
|
|
meillo@106
|
98 regarding the use cases and the email features,
|
|
meillo@106
|
99 as well as the reactions to them.
|
|
meillo@31
|
100 Socially, this document describes the effects
|
|
meillo@28
|
101 and experiences of a newcomer with revolutionary aims entering an old
|
|
meillo@53
|
102 and matured software project.
|
|
meillo@106
|
103 Philosophical thoughts on style, mainly based on the Unix
|
|
meillo@53
|
104 philosophy, are present throughout the discussions.
|
|
meillo@53
|
105 The document describes the changes to nmh,
|
|
meillo@53
|
106 but as well, it clarifies my personal perception of the
|
|
meillo@53
|
107 concepts of MH and Unix, and explain my therefrom resulting point of view.
|
|
meillo@23
|
108 .P
|
|
meillo@31
|
109 This document is written for the community around MH-like mail systems,
|
|
meillo@31
|
110 including developers and users.
|
|
meillo@106
|
111 Despite the focus on MH-like systems, this document may be valuable
|
|
meillo@106
|
112 to anyone interested in the Unix philosophy and anyone in contact with
|
|
meillo@106
|
113 old software projects, be it code- or community-related.
|
|
meillo@28
|
114 .P
|
|
meillo@106
|
115 The reader is expected to be familiar with Unix, C and emailing.
|
|
meillo@53
|
116 Good Unix shell knowledge is required, because MH relies fundamentally
|
|
meillo@125
|
117 on the shell. Without the power of the shell, MH becomes a motorcycle
|
|
meillo@30
|
118 without winding roads: boring.
|
|
meillo@31
|
119 Introductions to Unix and its shell can be found in ``The UNIX Programming
|
|
meillo@37
|
120 Environment'' by Kernighan and Pike
|
|
meillo@37
|
121 .[
|
|
meillo@37
|
122 kernighan pike unix prog env
|
|
meillo@37
|
123 .]
|
|
meillo@37
|
124 or ``The UNIX System'' by Bourne.
|
|
meillo@37
|
125 .[
|
|
meillo@37
|
126 bourne unix system
|
|
meillo@37
|
127 .]
|
|
meillo@53
|
128 The reader is assumed to be a C programmer,
|
|
meillo@53
|
129 but the document should be understandable otherwise, too.
|
|
meillo@53
|
130 The definitive guide to C is Kernighan and Ritchie's
|
|
meillo@53
|
131 ``The C Programming Language''.
|
|
meillo@37
|
132 .[
|
|
meillo@37
|
133 kernighan ritchie c prog lang
|
|
meillo@37
|
134 .]
|
|
meillo@164
|
135 A book about system-level C programming, such as those written by
|
|
meillo@164
|
136 Rochkind and Curry,
|
|
meillo@37
|
137 .[
|
|
meillo@37
|
138 rochkind advanced unix prog
|
|
meillo@37
|
139 .]
|
|
meillo@37
|
140 .[
|
|
meillo@37
|
141 curry system prog
|
|
meillo@37
|
142 .]
|
|
meillo@164
|
143 can be helpful as additional literature.
|
|
meillo@106
|
144 Old books are likely more helpful for understanding,
|
|
meillo@106
|
145 because large parts of the source code are old.
|
|
meillo@53
|
146 The reader is expected to know the format of email messages and
|
|
meillo@53
|
147 the structure of email transfer systems, at least on a basic level.
|
|
meillo@53
|
148 It's advisable to have cross-read the RFCs 821 and 822.
|
|
meillo@31
|
149 Further more, basic understanding of MIME is good to have.
|
|
meillo@106
|
150 The Wikipedia provides good introduction-level information about email.
|
|
meillo@53
|
151 .P
|
|
meillo@28
|
152 Frequent references to the Unix philosophy will be made.
|
|
meillo@53
|
153 Gancarz has tried to sum it up in his book
|
|
meillo@34
|
154 ``The UNIX Philosophy''.
|
|
meillo@34
|
155 .[
|
|
meillo@34
|
156 gancarz unix phil
|
|
meillo@34
|
157 .]
|
|
meillo@47
|
158 Even better, though less concrete, are ``The UNIX Programming Environment''
|
|
meillo@34
|
159 .[
|
|
meillo@34
|
160 kernighan pike unix prog env
|
|
meillo@34
|
161 .]
|
|
meillo@34
|
162 and ``The Practice of Programming''
|
|
meillo@34
|
163 .[
|
|
meillo@34
|
164 kernighan pike practice of prog
|
|
meillo@34
|
165 .]
|
|
meillo@34
|
166 by Kernighan and Pike.
|
|
meillo@34
|
167 The term paper ``Why the Unix Philosophy still matters''
|
|
meillo@34
|
168 .[
|
|
meillo@34
|
169 why unix phil still matters schnalke
|
|
meillo@34
|
170 .]
|
|
meillo@34
|
171 by myself
|
|
meillo@53
|
172 provides an overview on the philosophy, including a case study of MH.
|
|
meillo@53
|
173 .P
|
|
meillo@30
|
174 Although a brief introduction to MH is provided in Chapter 1, the reader
|
|
meillo@53
|
175 is encouraged to have a look at the \fIMH Book\fP
|
|
meillo@53
|
176 ``MH & nmh: Email for Users & Programmers'' by Jerry Peek.
|
|
meillo@34
|
177 .[
|
|
meillo@34
|
178 peek mh
|
|
meillo@34
|
179 .]
|
|
meillo@53
|
180 The current version is available freely on the Internet.
|
|
meillo@30
|
181 It is the definitive guide to MH and nmh.
|
|
meillo@30
|
182 .P
|
|
meillo@30
|
183 This document is neither a user's tutorial to mmh nor an introduction
|
|
meillo@53
|
184 to any of the topics covered.
|
|
meillo@53
|
185 The technical discussions are on an advanced level.
|
|
meillo@52
|
186 Nevertheless, as knowledge of the fundamental concepts is the most valuable
|
|
meillo@51
|
187 information a user can acquire about some program or software system,
|
|
meillo@52
|
188 this document may be worth a read for non-developers as well.
|
|
meillo@8
|
189
|
|
meillo@8
|
190
|
|
meillo@28
|
191 .U2 "Organization
|
|
meillo@0
|
192 .P
|
|
meillo@143
|
193 This thesis consists of three chapters.
|
|
meillo@143
|
194 Chapter 1 introduces into the topic, describing MH and explaining
|
|
meillo@143
|
195 the background and goals of the mmh project.
|
|
meillo@143
|
196 Chapter 2 discusses the work done in the project.
|
|
meillo@143
|
197 It is organized along the three major goals of the project, namely
|
|
meillo@143
|
198 streamlining, modernizing, and styling.
|
|
meillo@164
|
199 Not every change is described because that would bore the reader.
|
|
meillo@143
|
200 Instead, important changes and those standing for a set of similar
|
|
meillo@143
|
201 changes are described and discussed.
|
|
meillo@143
|
202 Chapter 3 finishes up by summarizing the achivements and taking
|
|
meillo@164
|
203 a look into the future of the mmh project.
|
|
meillo@28
|
204 .P
|
|
meillo@143
|
205 .I "Italic font
|
|
meillo@171
|
206 is used to emphasize new terms, and to name software projects and
|
|
meillo@171
|
207 man pages.
|
|
meillo@143
|
208 .CW "Constant width font
|
|
meillo@143
|
209 is used to denote names of programs, files,
|
|
meillo@143
|
210 functions, command lines, code excrepts, program input and output.
|
|
meillo@143
|
211 .P
|
|
meillo@143
|
212 References to man pages are printed as ``\c
|
|
meillo@143
|
213 .Mp cat (1)''.
|
|
meillo@143
|
214 In this case it is a reference to the man page of
|
|
meillo@143
|
215 .Pn cat ,
|
|
meillo@143
|
216 which is in section one of the Unix manual.
|
|
meillo@143
|
217 Internet technologies are specified by \fIRequests for Comments\fP (RFCs).
|
|
meillo@143
|
218 Throughout the document, they are referenced in this way ``RFC\|822''.
|
|
meillo@143
|
219 A list of relevant RFCs is located at the end of the document.
|
|
meillo@143
|
220 References to literature are printed in backets, like
|
|
meillo@143
|
221 .[ ``[
|
|
meillo@143
|
222 kernighan pike unix programming env
|
|
meillo@143
|
223 .]]'', within the text.
|
|
meillo@143
|
224 The full references are collected at the end of the document.
|
|
meillo@143
|
225 .P
|
|
meillo@143
|
226 This document describes practical programming work.
|
|
meillo@143
|
227 The code of mmh is managed by the
|
|
meillo@143
|
228 .Pn git
|
|
meillo@143
|
229 version control system.
|
|
meillo@143
|
230 All code changes were checked in.
|
|
meillo@143
|
231 In the discussions, references to corresponding code changes are printed
|
|
meillo@143
|
232 as ``\c
|
|
meillo@143
|
233 .Ci 1a2b3c4 ''.
|
|
meillo@143
|
234 The identifier is the seven-letter-prefix of the changeset hash value,
|
|
meillo@143
|
235 which is considered unique.
|
|
meillo@143
|
236 A change can be looked up in the repository, on the command line with
|
|
meillo@143
|
237 .Cl "git show XXX" ,
|
|
meillo@143
|
238 replacing `\f(CWXXX\fP' with the concrete hash value or any unique prefix.
|
|
meillo@68
|
239 In this example:
|
|
meillo@143
|
240 .Cl "git show 1a2b3c4" .
|
|
meillo@143
|
241 At the time of writing, changesets can be looked up online this way:
|
|
meillo@143
|
242 .CW "http://git.marmaro.de/?p=mmh;a=commitdiff;h=XXX" .
|
|
meillo@146
|
243 But as we all know, URIs are always at risk to change.
|
|
meillo@24
|
244
|
|
meillo@23
|
245
|
|
meillo@28
|
246 .U2 "Acknowledgments
|
|
meillo@23
|
247 .P
|
|
meillo@24
|
248 To be written at the very end.
|
|
meillo@143
|
249 .P
|
|
meillo@143
|
250 FIXME
|
