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