docs/master
view preface.roff @ 30:d996f130e279
Some rework and new text in the Preface.
author | markus schnalke <meillo@marmaro.de> |
---|---|
date | Wed, 09 May 2012 15:50:40 +0200 |
parents | 6c63083b4c19 |
children | 029e11dd4de1 |
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 creating an experimental version of nmh,
9 named \fImmh\fP,
10 to modernize, stream-line and to exploit the concepts
11 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 mutt, like many command line-attracted Unix users do.
17 The concepts of nmh had convinced me at once and thus learning
18 its different model of email handling had been relatively easy.
19 The change was like
20 managing files in the Unix shell when being used to graphical file
21 managers, or like learning vi when being used to modeless editors.
22 The transition had not been trivial but, as I was convinced by the new
23 concepts and
24 already managed my files with shell tools and edited with vi, not too
25 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 in handling attachments, non-ASCII character encodings,
33 and similar features of modern emailing.
34 My setup required more and more additional configuration and helper scripts
35 to have nmh act the way I expected it to behave, although my
36 expectations were rather common for modern emailing than exceptionel.
37 In being a software developer, I wanted to improve the situation.
38 .P
39 In Spring 2010, I asked on the nmh-workers mailing list for the
40 possibility to offer a Google Summer of Code project on nmh.
41 Participating in the development this way appeared attractive to me,
42 especially as it would have been possible to have the project
43 accepted at university. Although the nmh community
44 generally had been positive on the
45 suggestion, eventually it had not been possible to manage the
46 administrative work. Though my proposal had started the nmh community
47 to move. In the following weeks, goals for nmh's future were discussed
48 on the list. During the discussions, I became involved in the
49 question whether nmh should be an MTA. (Thread subject:
50 ``should nmh be an MTA or an MUA?''.)
51 In this point, my opinion differed from the opinion of most others
52 as I voted for the MTA facility of nmh to be removed.
53 .P
54 Being unable to work on nmh in a way that would be
55 accepted as part of my official studies, I had to pick another project.
56 Half a year later, starting in August 2010,
57 I took one semester off to travel through Latin America.
58 Within this time, I had to do practical computer work for three
59 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 and Internet connection for
64 my work.
65 Within the three month, I became familiar with nmh's code base and
66 its community. I learned how things work. Quickly it became obvious that
67 I wouldn't succeed with my main goal, to improve the character
68 encoding handling within the project. One obvious problem is the missing
69 transfer decoding of the quoted text in replies.
70 As this is one of the most intricate parts of the system, the goal
71 was simply too difficult to reach.
72 Instead I improved the code as I read through it. I found minor bugs
73 for which I proposed fixes to the community. Also I
74 could improve the documentation. When I started with
75 larger code changes, I had to discover that the community's wish for
76 compatibility was stronger than its wish for convenient
77 out-of-the-box setups \(en in contrast with my opinion.
78 This lead to long discussions, again.
79 I came to understand their point of view, but it simply is not mine.
80 .P
81 At the end of my three-month project, I had become familiar with
82 nmh's code base and its community. I had improved the project a bit
83 and I still was convinced that I wanted to go on with that.
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 long discussions and thus few progress.
91 After careful thought, I decided to start an experimental version of nmh.
92 I wanted to follow my own ideas of how nmh should look like. I wanted
93 to see where that would lead to. I wanted to compare the result of my
94 work to the present state of nmh. Time should prove me successful or
95 not.
96 Nmh would hardly be hurt by my work as I would not interfere with
97 them. But nmh would profit from my experiences.
99 .U2 "Focus of this Document
100 .P
101 This document describes my work on the experimental version, named
102 \fImmh\fP. It explains the changes I did to nmh, with having the focus
103 on the reasons for the changes. It discusses technical, historical,
104 social and philosophical reasons. On the technical side, this document
105 explains how an existing project was stream-lined by exploiting the
106 central concepts better and removing rough edges. On the historical
107 side, changes in the use cases and the features of email and reactions
108 to them are discussed. Socially, this document describes the effects
109 and experiences of a newcomer with revolutionary aims entering an old
110 and matured software projects and its community. Finally, philosophical
111 thoughts on style, mainly based to the Unix philosophy, are present
112 throughout the discussions.
113 .P
114 This document is written for the community around MH-like mail systems
115 \(en developers and users.
116 First of all, the document shall propagade the design goals and
117 implementation decisions of mmh. But as well, it shall clarify my
118 personal perception of the
119 concepts of MH and Unix, and explain the therefrom resulting point of view.
120 Despite the focus on MH-like systems, this document can be worthwhile
121 to anyone interested in the Unix philosophy, as well as anyone
122 involved in old software projects, be it code or community-related.
123 .P
124 The reader is expected to have good knowledge of Unix, C and emailing.
125 Good Unix shell
126 knowledge, including shell scripting, is required. MH relies fundamentally
127 on the shell. Without the power of the shell, MH becomes a motorbike
128 without winding roads: boring.
129 Introductions to Unix and its shell can be found in XXX.
130 The reader is
131 expected to be familiar with the C programming language, although the
132 document should be understandable without knowledge of C, too.
133 The book by Kernighan and Ritchie is the definitive guide to C.
134 Some book about system-level C programming is worthwile additional
135 literature. Rochkind and Curry have written such books.
136 As large parts of the code are old, old books are likely more helpful.
137 The format of email messages as well as the structure of email transfer
138 systems should be familiar to the reader, at least on a basic level.
139 It's advisable to have had, at least cross-read, the RFCs 821 and 822.
140 The book XXX introduces email well, too.
141 Frequent references to the Unix philosophy will be made.
142 Gancarz XXX had tried to sum the philosophy up. Even better but less
143 concrete is the literature by Kernighan and Pike XXX.
144 The term paper ``Why the Unix Philosophy still matters'' by myself
145 provides an overview on the topic, including a case study of MH.
146 Although a brief introduction to MH is provided in Chapter 1, the reader
147 is encouraged to have a look at the \fIMH Book\fP by Jerry Peek.
148 It is the definitive guide to MH and nmh.
149 The current version is available freely on the Internet XXX.
150 .P
151 This document is neither a user's tutorial to mmh nor an introduction
152 to any of the topics covered. It contains discussions on Unix, email
153 and system design on an advanced level.
154 However, as knowledge of the fundamental concepts is the most valuable
155 information over some program or software system a user can aquire,
156 this document might be worth a read for non-developers too.
159 .U2 "Organization
160 .P
161 Which font for what use.
162 Meaning of `foo(1)'.
163 RFCs.
164 MH vs. nmh vs. mmh.
165 .P
166 This thesis is devided into XXX chapters, ...
167 .P
168 .I Chapter 1
169 introduces ...
170 .P
171 .I Chapter 2
172 describes ...
173 .P
174 .I Chapter 3
175 covers ...
178 .U2 "Acknowledgments
179 .P
180 To be written at the very end.
183 .\" End or Preface. Start of the normal text.
184 .\" Switch to arabic page numbers and start on a right page.
185 .
186 .if e \{
187 . pn 1
188 . af PN 1
189 .\}
190 .if o \{
191 . pn 0
192 . af PN 0
193 . bp
194 .\}