Mercurial > docs > master

comparison ch01.roff @ 47:eae5e50381ce

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Rework in Preface and Intro.
author markus schnalke <meillo@marmaro.de>
date Fri, 18 May 2012 11:21:51 +0200
parents 7a33b5adb672
children d28ff07dfc0f d3a02f5e63b3
comparison
equal deleted inserted replaced
46:c9fc47c89d54 47:eae5e50381ce
1 .RN 1 1 .RN 1
2 2
3 .H0 "Introduction 3 .H0 "Introduction
4 .P 4 .P
5 This chapter introduces MH, its history, concepts and how it is used. 5 This chapter introduces MH, its history, concepts and how it is used.
6 Then, it describes nmh's code base and community to give the reader 6 It describes nmh's code base and community to give the reader
7 a better understanding of the state from which mmh started off. 7 a better understanding of the state from which mmh started off.
8 Further more, this chapter lists the motivation and goals of the mmh project. 8 Further more, this chapter outlines the mmh project itself,
9 This chapter introduces MH, nmh and mmh to the reader and outlines 9 describing the motivation for it and its goals.
10 the mmh project itself.
11 10
12 11
13 .H1 "MH \(en the Mail Handler 12 .H1 "MH \(en the Mail Handler
14 .P 13 .P
15 MH is an electronic mail system, originating in the RAND Corporation. 14 MH is a conceptual email system design and its concrete implementation.
16 Most important for this thesis is that MH defines a mail handling concept. 15 Notably, MH had started as a design proposal at RAND Corporation,
17 In fact, MH had started as a design proposal, not as an implementation, 16 where the first implementation followed later.
18 and in spirit it had remained this way. This is similar to Unix, which 17 In spirit, MH is similar to Unix, which
19 influenced the world more in being a set of system design concepts 18 influenced the world more in being a set of system design concepts
20 than in being a specific software product. 19 than in being a specific software product.
21 These ideas behind Unix are summarized in the \fIUnix philosophy\fP. 20 The ideas behind Unix are summarized in the \fIUnix philosophy\fP.
22 MH follows this philosophy. 21 MH follows this philosophy.
23 22
24 .U2 "History 23 .U2 "History
25 .P 24 .P
26 MH is an electronic mail system, originating in the RAND Corporation.
27 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines 25 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
28 had proposed the design 26 had proposed the design
29 of a new mail handling system, called ``Mail Handler'' (MH), 27 of a new mail handling system, called ``Mail Handler'' (MH),
30 to superseed RAND's old monolithic ``Mail System'' (MS). 28 to superseed RAND's old monolithic ``Mail System'' (MS).
31 Two years later, in 1979, Bruce Borden took the proposal and implemented a 29 Two years later, in 1979, Bruce Borden took the proposal and implemented a
32 prototype of MH. 30 prototype of MH.
33 Before the prototype had been available, the concept was 31 Before the prototype had been available, the concept was
34 believed to be practically unusable because of being too slow. 32 believed to be practically unusable.
35 But the prototype proved successful and replaced MS thereafter. 33 But the prototype had proven successful and replaced MS thereafter.
36 In replacing MS, MH became an all-in-one mail system. 34 In replacing MS, MH grew to an all-in-one mail system.
37 .P 35 .P
38 A decade later, the University of California at Irvine had started to use MH. 36 In the early Eighties,
37 the University of California at Irvine (UCI) had started to use MH.
39 They also took over its development and pushed MH forward. 38 They also took over its development and pushed MH forward.
40 This was the time when the Internet appeared, UCB implemented 39 Marshall T. Rose and John L. Romine became the driving force then.
41 the TCP/IP stack, and Allman wrote Sendmail. 40 This was the time when the Internet appeared, when UCB implemented
42 MH was extended as emailing got more features. 41 the TCP/IP stack, and when Allman wrote Sendmail.
42 MH was extended as emailing became more featured.
43 The development of MH was closely related to the development of email 43 The development of MH was closely related to the development of email
44 RFCs. In the advent of MIME, MH was the first implementation of this new 44 RFCs. In the advent of MIME, MH was the first implementation of this new
45 email standard. 45 email standard.
46 .P 46 .P
47 In the nineties, MH had been moved into the public domain, making it 47 In the Nineties, MH had been moved into the public domain, making it
48 attractive to Free Software developers. 48 attractive to Free Software developers.
49 The Internet had started to become popular and in 1997, 49 The Internet had became popular and in December 1996,
50 Richard Coleman initiated the ``New Mail Handler'' (nmh) project, 50 Richard Coleman initiated the ``New Mail Handler'' (nmh) project.
51 a fork of MH, based on the \fILBL changes\fP by Van Jacobson, Mike Karels 51 The project is a fork of MH 6.8.3 and bases strongly on the
52 and Craig Leres. 52 \fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres.
53 Colman intended to modernize MH and improve its portability and 53 Colman intended to modernize MH and improve its portability and
54 MIME handling capabilities. 54 MIME handling capabilities.
55 This should be done openly within the Internet community. 55 This should be done openly within the Internet community.
56 The development of MH stopped soon after the development of nmh had started. 56 The development of MH at UCI stopped after the 6.8.4 release in
57 February 1996, soon after the development of nmh had started.
57 Today, nmh almost completely replaced the original MH. 58 Today, nmh almost completely replaced the original MH.
59 Some systems might still provide old MH, but mainly for historical reasons.
60 .P
61 In the last years, the work on nmh was mostly maintenance work.
62 However, the development revived in December 2011 and stayed busy since then.
58 63
59 .U2 "Concepts 64 .U2 "Concepts
60 .P 65 .P
61 MH is a toolchest, modelled after the Unix toolchest. It consists of a 66 MH is a toolchest, modelled after the Unix toolchest. It consists of a
62 set of tools, each covering a specific task of email handling. 67 set of tools, each covering a specific task of email handling, like
63 The programs 68 composing a message, replying to a message, refiling a message to a
64 operate on a common mail storage. The specific format of the mail storage 69 different folder, listing the messages in a folder.
65 characterizes MH in the same way like the format of the file system 70 All of the programs operate on a common mail storage.
66 characterizes Unix.
67 .P 71 .P
68 The mail storage consists of \fImail folders\fP (directories) and 72 The mail storage consists of \fImail folders\fP (directories) and
69 \fPmessages\fP (regular files). 73 \fPmessages\fP (regular files).
70 Each message is stored in a separate file in the format it had been 74 Each message is stored in a separate file in the format it had been
71 received (i.e. transfer format). The files are named with ascending numbers 75 received (i.e. transfer format).
72 in each folder. 76 The files are named with ascending numbers in each folder.
73 .P 77 The specific format of the mail storage characterizes MH in the same way
74 MH tools maintain a \fIcontext\fP, which includes 78 like the format of the file system characterizes Unix.
75 the current mail folder and current message. 79 .P
80 MH tools maintain a \fIcontext\fP, which includes the current mail folder.
76 Processes in Unix have a similar context, containing the current working 81 Processes in Unix have a similar context, containing the current working
77 directory, for instance. In contrast, the process context is maintained 82 directory, for instance. In contrast, the process context is maintained
78 by the Unix kernel automatically, whereas MH tools need to maintain the MH 83 by the Unix kernel automatically, whereas MH tools need to maintain the MH
79 context themselves. 84 context themselves.
80 The user can have one MH context or multiple ones, he can even share it 85 The user can have one MH context or multiple ones, he can even share it
81 with other users. 86 with other users.
82 .P 87 .P
83 Messages can have symbolic names. These can be automatically updated 88 Messages are named by their numeric filename, but they can have symbolic names,
89 too. These are either automatically updated
84 position names like being the next or the last message, 90 position names like being the next or the last message,
85 or user-settable group names for arbitrary sets of messages. 91 or user-settable group names for arbitrary sets of messages.
86 These names are called sequences. 92 These names are called sequences.
87 Sequences can be bound to the folder or to the context. 93 Sequences can be bound to the containing folder or to the context.
88 .P 94 .P
89 New MH tools are built out of or on top of existing ones easily \(en 95 The user's \fIprofile\fP is a file that contains his MH configuration.
90 a property common to toolchests. 96 Default switches for the individual tools can be specified to
91 Multiple versions of the same command with different default values 97 adjust them to the user's personal preferences.
92 are created very easily. This provides shortcuts and tayloring. 98 Multiple versions of the same command with different
93 Form templates for new messages or for replies are easily exchangable. 99 default values can also be created very easily.
94 Generally, output is adjustable with format files. 100 Form templates for new messages or for replies are easily changable,
95 .P 101 and output is adjustable with format files.
96 The configuration is stored in a file that is called the user's \fIprofile\fP.
97 MH encourages the user to taylor and automate the mail handling.
98 Almost every part of the system can be adjusted to personal preference. 102 Almost every part of the system can be adjusted to personal preference.
103 .P
99 The system is well scriptable and extendable. 104 The system is well scriptable and extendable.
105 New MH tools are built out of or on top of existing ones quickly.
106 Further more, MH encourages the user to taylor, extend and automate the system.
100 As the MH toolchest was modelled after the Unix toolchest, the 107 As the MH toolchest was modelled after the Unix toolchest, the
101 properties of the latter apply to the former as well. 108 properties of the latter apply to the former as well.
102 109
103 .U2 "Versions
104 .P
105 Three versions of MH are available today:
106 .IP "Old MH"
107 .br
108 In most cases this version had been replaced by nmh,
109 but some systems might still provide old MH.
110 The main reasons to still use old MH are historical reasons.
111 MH provides hardly any benefits over nmh.
112 The development of old MH has stopped after the 6.8.4 release in
113 February 1996.
114 .IP nmh
115 .br
116 The most widespread version of MH was forked off version 6.8.3 in December
117 1996. It is based on the \fILBL changes\fP.
118 Backward-compatibility to old MH is provided by having new featues deactivated
119 by default. In consequence, the user needs to activate them explicitely to
120 be able to use them.
121 Throughout the previous years, the work on nmh was mostly maintenance work.
122 Development revived in December 2011 and stayed busy since then.
123 .IP mmh
124 .br
125 This descendent of nmh is the subject of this thesis.
126 It had started as an experimental version, but became de facto a fork.
127 110
128 .U2 "Example Session 111 .U2 "Example Session
129 .P 112 .P
130 Following is an example mail handling session with mmh. 113 Following is an example mail handling session with mmh.
131 It should be mostly compatible with nmh and old MH. 114 It should be mostly compatible with nmh and old MH.
206 also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP) 189 also lead to duplicated functions (e.g. \fLshow\fP, \fLmhshow\fP)
207 and had not been thoroughly included into the concepts (e.g. the 190 and had not been thoroughly included into the concepts (e.g. the
208 user-visible access to whole messages and MIME parts are inherently 191 user-visible access to whole messages and MIME parts are inherently
209 different). 192 different).
210 .P 193 .P
211 For compatibility's sake, it is a common understanding to have the 194 For backward-compatibility's sake, it is a common understanding to have the
212 default settings to be compatible, requiring any new feature to be 195 default settings to be compatible, requiring any new feature to be
213 explicitely enabled. This puts a burden on new users, because nmh 196 explicitely enabled.
197 In consequence, the user needs to activate modern features explicitely
198 to be able to use them.
199 This puts a burden on new users, because nmh
214 out-of-the-box keeps staying in the same ancient style, where users 200 out-of-the-box keeps staying in the same ancient style, where users
215 usually want to have it practical for modern emailing. 201 usually want to have it practical for modern emailing.
216 But of course, this depends on if nmh is seen to be a front-end or a 202 But of course, this depends if nmh is seen to be a front-end or a
217 back-end. 203 back-end.
218 204
219 205
220 .H1 "mmh 206 .H1 "mmh
221 .P 207 .P
248 dwm had remained much more focused on its original goals, 234 dwm had remained much more focused on its original goals,
249 whereas its community-driven predecessor \fIwmii\fP had 235 whereas its community-driven predecessor \fIwmii\fP had
250 grown large and lost it's leanness. 236 grown large and lost it's leanness.
251 This should not happen to mmh. 237 This should not happen to mmh.
252 .P 238 .P
253 mmh can also stand for \fImodern mail handler\fP, and this is 239 Mmh can also stand for \fImodern mail handler\fP, and this is
254 the variant chosen as titel for this document. One main focus of the 240 the variant chosen as titel for this document. One main focus of the
255 project was to modernize nmh. Another main goal is resembled in the 241 project was to modernize nmh. Another main goal is resembled in the
256 name \fIminimized mail handler\fP: Drop any parts that don't add 242 name \fIminimized mail handler\fP: Drop any parts that don't add
257 to the main task of mmh, being a MUA. 243 to the main task of mmh, being a MUA.
258 .P 244 .P