comparison ch01.roff @ 8:3ef5449c1175

Moved text; wrote more text; removed ch02.roff.
author markus schnalke <meillo@marmaro.de>
date Wed, 07 Mar 2012 16:04:08 +0100
parents f3425905d7d1
children 34727751be7e
comparison
equal deleted inserted replaced
7:7497062adc82 8:3ef5449c1175
1 .H0 "Introduction 1 .H0 "Introduction
2 .P 2 .P
3 This chapter describes the background of the topics in this thesis. 3 This chapter describes the background of the topics in this thesis.
4 General knowledge of electronic mail is assumed. 4 General knowledge of electronic mail is assumed.
5 It explains the situation at the start of the project.
6 It tries to describe from what state the project lifted of and where
7 it headed to. This shall give an overview.
8
5 9
6 .H1 "What is MH? 10 .H1 "What is MH?
7 .P 11 .P
8 MH is an electronic mail system, originating in the RAND Corporation. 12 MH is an electronic mail system, originating in the RAND Corporation.
9 Historically, it had been a all-in-one mail system, with Mail Transfer 13 Historically, it had been a all-in-one mail system, with Mail Transfer
15 .P 19 .P
16 First of all, MH is a style of a mail handling system. 20 First of all, MH is a style of a mail handling system.
17 It had started as a design proposal, not as an implementation, and 21 It had started as a design proposal, not as an implementation, and
18 had in spirit remained so. This is similar to Unix, which much less 22 had in spirit remained so. This is similar to Unix, which much less
19 is a specific software product, as it is a style of system design. 23 is a specific software product, as it is a style of system design.
20 MH is a toolchest of programs, modelled after the Unix toolchest,
21 and it is a specific mail storage format, like Unix has its file system
22 formats.
23 24
24 .H2 "Concepts of MH" no 25 .H2 "History" no
25 .P
26 FIXME
27
28 .H2 "History of MH" no
29 .P 26 .P
30 MH is an electronic mail system, originating in the RAND Corporation. 27 MH is an electronic mail system, originating in the RAND Corporation.
31 In 1977, Norman Shapiro and Stockton Gaines had proposed the design 28 In 1977, Norman Shapiro and Stockton Gaines had proposed the design
32 of a new mail handling system, called ``Mail Handler'' (MH) for RAND, 29 of a new mail handling system, called ``Mail Handler'' (MH) for RAND,
33 to superseed their ``Mail System'' (MS). 30 to superseed their ``Mail System'' (MS).
44 attractive to Free Software developers. The Internet had started to become 41 attractive to Free Software developers. The Internet had started to become
45 mainstream and in 1997, Richard Coleman initiated the ``New Mail Handler'' 42 mainstream and in 1997, Richard Coleman initiated the ``New Mail Handler''
46 (nmh), a fork of MH. He intended to modernize MH, improve its MIME 43 (nmh), a fork of MH. He intended to modernize MH, improve its MIME
47 capabilities, and this should be done openly within the Internet 44 capabilities, and this should be done openly within the Internet
48 community. Today, nmh almost completely replaced the original MH. 45 community. Today, nmh almost completely replaced the original MH.
46 .P
47 Three versions of MH are currently available:
48 .BU
49 .B "Old MH" .
50 In most cases it has been replaced by nmh, but there are still systems
51 that provide old MH. As nmh is old MH-compatible, there exist few reasons
52 not to upgrade to new.
53 The development of old MH stopped almost completely.
54 .BU
55 .B Nmh .
56 The most widespread version of MH. Backward-compatible to old MH.
57 Provides new featues, which need to be activated explicitely.
58 Its development went slowly in the previous years, but had revived
59 in Fall 2011.
60 .BU
61 .B Mmh
62 A descendent of nmh. Had started as a non-compatible experimental
63 version, but became de facto a fork. Tries to expand the same
64 principal concepts in a more modern way. This version of MH is the
65 subject of this thesis.
49 66
50 .H1 "How the Fun Began 67 .H2 "Concepts" no
51 .P 68 .P
52 I have discovered nmh in XXX. I used to use mutt, like many 69 MH is a toolchest, modelled after the Unix toolchest. It consists of a
53 command line-attracted Unix users. Nmh had convinced me conceptually 70 bunch of tools, each covering one task of email handling. These programs
54 at once. Unfortunately, setting it up to a convenient state became a 71 operate on a common mail storage. The specific format of the mail storage
55 tendious task. Learning its different model of email handling had, 72 also defines MH, like the file system structure defines Unix. It
56 in contrast, been relatively easy. Learning to use MH if you are used 73 consists of directories (mail folders) and files (mail messages).
57 to monolithic mail clients is like learning vi if you are used to 74 Each file contains exactly one message in the format it had been
58 modeless editors. 75 received (i.e. transfer format). MH tools carry a state (context),
59 Once having nmh set up, using it was joy because of its conceptional 76 consisting of current mail folder and current message. Messages can
60 elegance and scripting capabilities, but on the other hand it was 77 have symbolic names, like the next or last message or for some
61 inconvenient in handling attachments, non-ASCII character encodings, 78 arbitrary group of messages. These names are called sequences.
62 and similar stuff. I found it wrong to require more and more scripts
63 and configuration to have it act the expected way. In being a
64 software developer, I wanted to improve the situation.
65 .P 79 .P
66 In Spring 2010, I asked on the nmh-workers mailing list for the 80 New MH tools can be build out of existing ones easily. Default values to
67 possibility to have a Google Summer of Code project on nmh. Being a 81 commands are stored on a command name-basis, making it trivial to have
68 student, this appeared attractive to me. Eventually, it had not been 82 different versions of the same command with different defaults. Most
69 possible, but the nmh community started to move. In these months 83 of the configuration is stored in the user's profile. Form templates,
70 nmh's future was discussed and I became part of a ``Does nmh need an 84 e.g. for new messages or replies, are exchangeable and output is generally
71 MTA'' discussion. There, my opinion differed from the opinion of 85 adjustable with format files.
72 most others.
73 .P 86 .P
74 As it hadn't been possible to work on nmh in a way that would be 87 MH allows the user to automate almost everything and to modify amost
75 accepted as part of my official studies, I needed to get my credit 88 any behavior. The system is scriptable and extendable.
76 points in some other way. But half a year later I was back. Starting 89
77 in Summer 2010, I took one semester off to travel through Latin America. 90
78 Within this time, I needed to do practical computer work for three 91 .H1 "Understanding of the Code and Community
79 months. Richard Sandelman, an active nmh user, made it possible for
80 me to work on nmh during this time. Juan Granda, from Santiago del
81 Estero in Argentina, provided a computer and Internet connection.
82 Within these three month, I became familiar with nmh's code base and
83 its community. I learned how things work. Quickly it was obvious that
84 I wouldn't succeed to improve on the non-ASCII character encoding
85 problems, as this is one of the most intricate parts of the system.
86 Instead I improved code as I read through it. I found minor bugs in
87 the code and could improve the documentation. When I started with
88 larger code changes, I had to discover that the community's wish for
89 compatibility was stronger than its wish for convenient
90 out-of-the-box setups. This lead to long discussions, again. Finally,
91 I understand their point of view, but it's not mine.
92 At the end of my three-month project, I had became familiar with
93 nmh's code base and community, I had improved both a bit, and I still
94 was convinced that I wanted to go on with it.
95 .P 92 .P
96 Another half a year later, I needed a topic for my master's thesis. 93 In order to understand the state, goals and dynamics of a project,
97 Now it was clear: I wanted to work on nmh. No, not exactly nmh, 94 one needs to know its history. MH comes from a time before the
98 because I had accepted that the nmh community has different goals 95 Internet, a time before networking became universal, a time when
99 than I have. The won't be much progress if generally different opinions 96 emailing was small, short and simple. Then it grew, spread and
100 lead to long discussions. After careful thought, I had decided to 97 adopted to the changes. The core-concepts, however, remained the
101 start an experimental version of nmh. I wanted to go my way and see 98 same. During the XXX a small group of students at the University of
102 where it would lead to. Time would tell if it would prove successful. 99 California, actively worked on MH. They added features and optimized,
103 Nmh would hardly be hurt by my work, but could profit from my 100 like it is common for scientific work. This is still in pre-ANSI C
104 experiences later. 101 times. The source code contains many ancient parts. Code constructs
102 specific to BSD or hardware of that time are usual.
105 .P 103 .P
106 When I started to work on mmh, my experimental version, in Fall 2011, 104 Nmh started eight years after the ANSI C standard had been
107 activity in nmh rose suddenly. While I was working on mmh, XXX were 105 established. A more modern coding style entered the code base. Still
108 working on nmh. After long years of idleing, nmh was actively 106 a part of the developers come from ``the old days''. The developer
109 developed again. That was a good sign. My own work went in parallel 107 base became more diverse and thus the code. Programming practices
110 and unrelated. Today, my experimental version became de facto a fork. 108 from different decades merged into the project. Different coding
111 The mail storage, however, is still compatible. 109 styles came together. It appears as if multiple peers added code
110 parts, resulting in a conclomeration rather than an homogenic
111 of-one-cast mail system. Still, the basic concepts hold it together.
112 They were mostly untouched throughout the years.
113 .P
114 Although, at the surface, nmh is a toolchest, meaning a collection
115 of completely modularized small programs, on the source code level,
116 it is much more interweaved. Parts of the basic functions are
117 collected in a MH standard library, which is good, but often
118 separate functions are compiled into programs, for effiency reasons.
119 This lead to intricate innards.
120 The advent of MIME rose the complexity of email by a magnitude. This
121 is visible in nmh. The MIME-related parts are the most complex ones.
122 It's also visible that MIME support had been added on top of the
123 original MH later. The MH style made this easily possible, but it
124 also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
125 and had not been thoroughly included into the concepts (e.g. the
126 user-visible access to whole messages and MIME parts are inherently
127 different).
128 .P
129 For compatibility's sake, it is a common understanding to have the
130 default settings to be compatible, requiring any new feature to be
131 explicitely enabled. This puts a burden on new users, because nmh
132 out-of-the-box keeps staying in the same ancient style, where users
133 usually want to have it practical for modern emailing.
134 But of course, this depends on if nmh is seen to be a front-end or a
135 back-end.
136
137
138 .H1 "My Vision
139 .P
140 The general goals of the mmh project are the following:
141 .BU
142 I believe that mmh should be perfectly suited for modern emailing,
143 out-of-the-box.
144 .BU
145 I care less about compatibility and more about conceptionally elegant
146 approaches.
147 .BU
148 I care for general, clear, and simple concepts.
149 .BU
150 I like to create an of-one-style email system. It should feel like
151 cast as one.
152 .BU
153 I plan to remove any optimizations that rises obscurity, unless it
154 appears to be neccessary to make mmh usable at all.
155 .P
156 .B "The target user in mind
157 likes Unix and its philosophy.
158 He likes to use programs that are conceptionally appealing.
159 He's familiar with the command line and enjoys its power.
160 He is at least capable of shell scripting and wants to improve his
161 productivity by scripting the mail system.
162 His computer and operating system are from post-ANSI C times.
163 He likes to attach files, exchanges text containing non-ASCII
164 characters, signs or encrypts his messages.
165 He does not use bulletin boards anymore, nor non-mbox style mail
166 drops, nor does he rely on compatibility to nmh.
167 He already has and MTA/MSA and MRA running or is able to set them
168 up.
169 He does not want to have to read a book in order to make his MUA
170 usable.
171
172
173 .H1 "Things to do
174 .BU
175 Remove any MTA and MRA facilities. Mmh shall concentrate on the MUA
176 task. Mail shall enter mmh's mail storage via the system mail drop
177 and it shall leave mmh via the local \fLsendmail\fP command.
178 .BU
179 Remove any further functions that are not related to mmh's main task.
180 Bulletin board support is on example. Also remove support for ancient
181 technologies, like hardcopy terminals.
182 .BU
183 Refactor the source code to meet modern style criteria. Use
184 standardized library functions when possible.
185 .BU
186 Replace performance optimizations by clear and readable code.
187 .BU
188 Reduce the feature set to the commonly used one, removing
189 corner-cases. Set sane default values.
190 .BU
191 Add better attachment support. Add support for digital signatures and
192 encryption.
193 .BU
194 Merge \fLshow\fP and \fLmhshow\fP into one single mail display program.
195 Integrate MIME support deeper and more natural into MH.
196 .BU
197 Provide a ready-to-use setup out-of-the-box.