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