docs/master
view preface.roff @ 49:d3a02f5e63b3
Various rework.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Sat, 19 May 2012 17:56:15 +0200 |
| parents | 22ae3981a76b |
| children | 49cf68506b5d |
line source
1 .H0 "Preface" no
3 .P
4 MH is a set of mail handling tools with a common concept, similar to
5 the Unix toolchest, which is a set of file handling tools with a common
6 concept. nmh is the currently most popular implementation of an
7 MH-like mail handling system.
8 This thesis describes an experimental version of nmh, named \fImmh\fP.
10 .U2 "Background to this Thesis
11 .P
12 I have discovered nmh in September 2009. At that time I used to use the
13 mail client \fImutt\fP, like many advanced Unix users do.
14 As I read about nmh, its concepts had convinced me at once.
15 Learning its different model of email handling had been relatively easy,
16 because my starting situation was being convinced of the concepts.
17 The transition from mutt to nmh was similar to
18 managing files in the Unix shell when being used to graphical file
19 managers, or like editing with vi when being used to modeless editors.
20 Such a change is not trivial, but in being convinced by the
21 concepts and by having done similar transitions for file management
22 and editing already, it was not too difficult neither.
23 In contrast, setting up nmh to a convenient state became a tendious task
24 that took several months.
25 .P
26 Once having nmh arranged to a convenient state, I enjoyed using it
27 because of its conceptional elegance and its scripting capabilities.
28 On the other hand, however, it still was
29 inconvenient for handling attachments, non-ASCII character encodings,
30 and similar features of modern emailing.
31 My setup demanded more and more additional configuration and helper scripts
32 to get nmh behave the way I wanted, although my
33 expectations were rather common for modern emailing.
34 In being a computer scientist and programmer,
35 I wanted to improve the situation.
36 .P
37 In Spring 2010, I asked on the \fInmh-workers\fP mailing list for the
38 possibility to offer a Google Summer of Code project.
39 Participating in the development this way appeared attractive to me,
40 as it would have been possible to have the project
41 accepted at university. Although generally the nmh community
42 had been positive on the
43 suggestion, the administrative work had been to much, eventually.
44 But my proposal had activated the nmh community.
45 In the following weeks, goals for nmh's future were discussed.
46 In these discussions, I became involved in the
47 question whether nmh should be an MTA.
48 .[
49 nmh-workers thread mta mua
50 .]
51 In this central point, my opinion differed from the opinion of most others.
52 I argued for the MTA facility of nmh to be removed.
53 Besides the discussions, hardly any real work was done.
54 Being unable to work on nmh in a way that would be
55 accepted as part of my official studies, I needed to choose another project.
56 .P
57 Half a year later, starting in August 2010,
58 I took one semester off to travel through Latin America.
59 Within this time, I had to do practical computer work for three months.
60 This brought me back to nmh.
61 Richard Sandelman, an active nmh user, made it possible for
62 me to work on nmh. Juan Granda, living in Santiago del
63 Estero in Argentina, provided a computer with Internet connection for
64 my work. Thanks to them, I was able to work on nmh during my three-month
65 stay in Argentina.
66 Within this time, I became familiar with nmh's code base and
67 community. I learned how things work. Quickly it became obvious that
68 I wouldn't succeed with my main goal: improving the character
69 encoding handling within the project. One of its ramifications is the
70 missing transfer decoding of quoted text in replies.
71 As this is one of the most intricate parts of the system, the goal
72 was simply set too high. Hence, I dropped the original plan.
73 Instead, I improved the code base as I read through it. I found minor bugs
74 for which I proposed fixes to the community. In the same go, I
75 improved the documentation in minor ways. When I started with
76 larger code changes, I had to discover that the community was reluctant
77 to change. Its wish for compatibility was much stronger than its
78 wish for convenient out-of-the-box setups \(en in contrast to my opinion.
79 This lead to long discussions, again.
80 I came to understand their point of view, but it is different to mine.
81 At the end of my three-month project, I had become familiar with
82 nmh's code base and community. I had improved the project in minor ways,
83 and I still was convinced that I wanted to go on to do so.
84 .P
85 Another half a year later, the end of my studies came within reach.
86 I needed a topic for my master's thesis.
87 There was no question: I wanted to work on nmh.
88 But well, not exactly on nmh,
89 because I had accepted that the nmh community has different goals
90 than I have. This would result in much discussion and thus little progress.
91 After careful thought, I decided to start an experimental version of nmh.
92 I wanted to implement my own ideas of how an MH-like system should look like.
93 I wanted to see where that would lead to.
94 I wanted to create a usable alternative version to be compared with
95 the present state of nmh.
96 My work should be proved successful or failed.
97 The nmh project would not be hurt by my work, but
98 it would profit from my experiences.
100 .U2 "Focus of this Document
101 .P
102 This document describes my work on mmh.
103 It explains the changes to nmh, with focus on their reasons.
104 It discusses technical, historical, social and philosophical considerations.
105 On the technical side, this document
106 explains how an existing project was stream-lined by removing rough edges
107 and exploiting the central concepts better.
108 On the historical
109 side, changes through time in the use cases and the email features,
110 as well as the reactions to them, are discussed.
111 Socially, this document describes the effects
112 and experiences of a newcomer with revolutionary aims entering an old
113 and matured software projects.
114 Finally, philosophical thoughts on style, mainly based to the Unix philosophy,
115 are present throughout the discussions.
116 .P
117 This document is written for the community around MH-like mail systems,
118 including developers and users.
119 First of all, the document shall explain the design goals and
120 implementation decisions for mmh. But as well, it shall clarify my
121 personal perception of the
122 concepts of MH and Unix, and explain my therefrom resulting point of view.
123 Despite the focus on MH-like systems, this document may be worthwhile
124 to anyone interested in the Unix philosophy and anyone in contact to
125 old software projects, be it code or community-related.
126 .P
127 The reader is expected to have good knowledge of Unix, C and emailing.
128 Good Unix shell
129 knowledge, including shell scripting, is required. MH relies fundamentally
130 on the shell. Without the power of the shell, MH becomes a motorbike
131 without winding roads: boring.
132 Introductions to Unix and its shell can be found in ``The UNIX Programming
133 Environment'' by Kernighan and Pike
134 .[
135 kernighan pike unix prog env
136 .]
137 or ``The UNIX System'' by Bourne.
138 .[
139 bourne unix system
140 .]
141 The reader is
142 expected to be familiar with the C programming language, although the
143 document should be understandable without knowledge of C, too.
144 ``The C Programming Language'' by Kernighan and Ritchie
145 .[
146 kernighan ritchie c prog lang
147 .]
148 is the definitive guide to C.
149 Some book about system-level C programming is worthwile additional
150 literature. Rochkind and Curry have written such books.
151 .[
152 rochkind advanced unix prog
153 .]
154 .[
155 curry system prog
156 .]
157 As large parts of the code are old, old books are likely more helpful
158 to understanding.
159 The format of email messages as well as the structure of email transfer
160 systems should be familiar to the reader, at least on a basic level.
161 It's advisable to have at least cross-read the RFCs 821 and 822.
162 Further more, basic understanding of MIME is good to have.
163 The Wikipedia provides good introduction-level information to email.
164 Frequent references to the Unix philosophy will be made.
165 Gancarz had tried to sum the philosophy up in his book
166 ``The UNIX Philosophy''.
167 .[
168 gancarz unix phil
169 .]
170 Even better, though less concrete, are ``The UNIX Programming Environment''
171 .[
172 kernighan pike unix prog env
173 .]
174 and ``The Practice of Programming''
175 .[
176 kernighan pike practice of prog
177 .]
178 by Kernighan and Pike.
179 The term paper ``Why the Unix Philosophy still matters''
180 .[
181 why unix phil still matters schnalke
182 .]
183 by myself
184 provides an overview on the topic, including a case study of MH.
185 Although a brief introduction to MH is provided in Chapter 1, the reader
186 is encouraged to have a look at the \fIMH Book\fP by Jerry Peek.
187 .[
188 peek mh
189 .]
190 It is the definitive guide to MH and nmh.
191 The current version is available freely on the Internet.
192 .P
193 This document is neither a user's tutorial to mmh nor an introduction
194 to any of the topics covered. It discusses Unix, email
195 and system design on an advanced level.
196 However, as knowledge of the fundamental concepts is the most valuable
197 information a user can aquire about some program or software system,
198 this document might be worth a read for non-developers as well.
201 .U2 "Organization
202 .P
203 Which font for what use.
204 Meaning of `foo(1)'.
205 RFCs.
206 .P
207 This thesis is devided into XXX chapters, ...
208 .P
209 .I Chapter 1
210 introduces ...
211 .P
212 .I Chapter 2
213 describes ...
214 .P
215 .I Chapter 3
216 covers ...
219 .U2 "Acknowledgments
220 .P
221 To be written at the very end.