docs/master

annotate ch01.roff @ 70:d6840bfbe04c

find changesets by author, revision, files, or words in the commit message
style: Use .substring to print only a prefix of the commit hash. I can decide later how long a prefix I like to print. If your troff doesn't support .substring, the whole hash is printed.
author markus schnalke <meillo@marmaro.de>
date Sat, 02 Jun 2012 12:39:23 +0200
parents d9c18bd9ed92
children ff4537327162
rev   line source
meillo@39 1 .RN 1
meillo@39 2
meillo@0 3 .H0 "Introduction
meillo@0 4 .P
meillo@53 5 MH is a set of mail handling tools with a common concept, similar to
meillo@53 6 the Unix tool chest, which is a set of file handling tools with a common
meillo@53 7 concept. \fInmh\fP is the currently most popular implementation of an
meillo@53 8 MH-like mail handling system.
meillo@53 9 This thesis describes an experimental version of nmh, named \fImmh\fP.
meillo@53 10 .P
meillo@32 11 This chapter introduces MH, its history, concepts and how it is used.
meillo@47 12 It describes nmh's code base and community to give the reader
meillo@32 13 a better understanding of the state from which mmh started off.
meillo@47 14 Further more, this chapter outlines the mmh project itself,
meillo@47 15 describing the motivation for it and its goals.
meillo@8 16
meillo@0 17
meillo@28 18 .H1 "MH \(en the Mail Handler
meillo@0 19 .P
meillo@47 20 MH is a conceptual email system design and its concrete implementation.
meillo@47 21 Notably, MH had started as a design proposal at RAND Corporation,
meillo@47 22 where the first implementation followed later.
meillo@47 23 In spirit, MH is similar to Unix, which
meillo@42 24 influenced the world more in being a set of system design concepts
meillo@32 25 than in being a specific software product.
meillo@47 26 The ideas behind Unix are summarized in the \fIUnix philosophy\fP.
meillo@42 27 MH follows this philosophy.
meillo@2 28
meillo@11 29 .U2 "History
meillo@2 30 .P
meillo@32 31 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
meillo@32 32 had proposed the design
meillo@32 33 of a new mail handling system, called ``Mail Handler'' (MH),
meillo@32 34 to superseed RAND's old monolithic ``Mail System'' (MS).
meillo@27 35 Two years later, in 1979, Bruce Borden took the proposal and implemented a
meillo@32 36 prototype of MH.
meillo@32 37 Before the prototype had been available, the concept was
meillo@47 38 believed to be practically unusable.
meillo@47 39 But the prototype had proven successful and replaced MS thereafter.
meillo@47 40 In replacing MS, MH grew to an all-in-one mail system.
meillo@2 41 .P
meillo@47 42 In the early Eighties,
meillo@47 43 the University of California at Irvine (UCI) had started to use MH.
meillo@47 44 Marshall T. Rose and John L. Romine became the driving force then.
meillo@57 45 They took over the development and pushed MH forward.
meillo@57 46 RAND had put the code into the public domain by then.
meillo@57 47 MH was developed at UCI at the time when the Internet appeared,
meillo@57 48 when UCB implemented the TCP/IP stack, and when Allman wrote Sendmail.
meillo@47 49 MH was extended as emailing became more featured.
meillo@32 50 The development of MH was closely related to the development of email
meillo@32 51 RFCs. In the advent of MIME, MH was the first implementation of this new
meillo@32 52 email standard.
meillo@2 53 .P
meillo@57 54 In the Nineties, the Internet had become popular and in December 1996,
meillo@47 55 Richard Coleman initiated the ``New Mail Handler'' (nmh) project.
meillo@57 56 Nmh is a fork of MH 6.8.3 and bases strongly on the
meillo@47 57 \fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres.
meillo@32 58 Colman intended to modernize MH and improve its portability and
meillo@32 59 MIME handling capabilities.
meillo@32 60 This should be done openly within the Internet community.
meillo@47 61 The development of MH at UCI stopped after the 6.8.4 release in
meillo@47 62 February 1996, soon after the development of nmh had started.
meillo@57 63 Today, nmh has almost completely replaced the original MH.
meillo@47 64 Some systems might still provide old MH, but mainly for historical reasons.
meillo@47 65 .P
meillo@47 66 In the last years, the work on nmh was mostly maintenance work.
meillo@57 67 However, the development revived in December 2011
meillo@57 68 and stayed busy since then.
meillo@0 69
meillo@11 70 .U2 "Concepts
meillo@0 71 .P
meillo@53 72 MH consists of a set of tools, each covering a specific task of
meillo@53 73 email handling, like composing a message, replying to a message,
meillo@53 74 refiling a message to a different folder, listing the messages in a folder.
meillo@47 75 All of the programs operate on a common mail storage.
meillo@42 76 .P
meillo@32 77 The mail storage consists of \fImail folders\fP (directories) and
meillo@32 78 \fPmessages\fP (regular files).
meillo@32 79 Each message is stored in a separate file in the format it had been
meillo@47 80 received (i.e. transfer format).
meillo@47 81 The files are named with ascending numbers in each folder.
meillo@47 82 The specific format of the mail storage characterizes MH in the same way
meillo@47 83 like the format of the file system characterizes Unix.
meillo@42 84 .P
meillo@47 85 MH tools maintain a \fIcontext\fP, which includes the current mail folder.
meillo@32 86 Processes in Unix have a similar context, containing the current working
meillo@32 87 directory, for instance. In contrast, the process context is maintained
meillo@32 88 by the Unix kernel automatically, whereas MH tools need to maintain the MH
meillo@32 89 context themselves.
meillo@32 90 The user can have one MH context or multiple ones, he can even share it
meillo@32 91 with other users.
meillo@42 92 .P
meillo@47 93 Messages are named by their numeric filename, but they can have symbolic names,
meillo@47 94 too. These are either automatically updated
meillo@32 95 position names like being the next or the last message,
meillo@32 96 or user-settable group names for arbitrary sets of messages.
meillo@32 97 These names are called sequences.
meillo@47 98 Sequences can be bound to the containing folder or to the context.
meillo@2 99 .P
meillo@47 100 The user's \fIprofile\fP is a file that contains his MH configuration.
meillo@47 101 Default switches for the individual tools can be specified to
meillo@47 102 adjust them to the user's personal preferences.
meillo@47 103 Multiple versions of the same command with different
meillo@47 104 default values can also be created very easily.
meillo@51 105 Form templates for new messages or for replies are easily changeable,
meillo@47 106 and output is adjustable with format files.
meillo@47 107 Almost every part of the system can be adjusted to personal preference.
meillo@42 108 .P
meillo@51 109 The system is well scriptable and extensible.
meillo@47 110 New MH tools are built out of or on top of existing ones quickly.
meillo@51 111 Further more, MH encourages the user to tailor, extend and automate the system.
meillo@51 112 As the MH tool chest was modeled after the Unix tool chest, the
meillo@32 113 properties of the latter apply to the former as well.
meillo@8 114
meillo@54 115 .U2 "Using MH
meillo@53 116 .P
meillo@54 117 It is strongly recommended to have a look at the MH Book,
meillo@54 118 which introduces well into using MH.
meillo@54 119 .[ [
meillo@54 120 peek mh book
meillo@54 121 .], Part II]
meillo@54 122 Rose and Romine provide a deeper and more technical
meillo@54 123 though slightly outdated introduction in only about two dozens pages.
meillo@54 124 .[
meillo@54 125 rose romine real work
meillo@54 126 .]
meillo@27 127 .P
meillo@53 128 Following is an example mail handling session.
meillo@53 129 It uses mmh but is mostly compatible with nmh and old MH.
meillo@32 130 Details might vary but the look'n'feel is the same.
meillo@42 131 .DS
meillo@42 132 $ \f(CBinc\fP
meillo@42 133 Incorporating new mail into inbox...
meillo@42 134
meillo@42 135 1+ 2012-05-16 11:16 meillo@dream.home Hello
meillo@42 136 2 2012-05-16 11:17 meillo@dream.home book
meillo@42 137
meillo@42 138 $ \f(CBshow\fP
meillo@42 139 Date: Wed, 16 May 2012 11:16:00 +0200
meillo@42 140 To: meillo
meillo@42 141 From: <meillo@dream.home.schnalke.org>
meillo@42 142 Subject: Hello
meillo@42 143
meillo@42 144 part text/plain 13
meillo@42 145 mmh is great
meillo@42 146
meillo@42 147 $ \f(CBnext\fP
meillo@42 148 Date: Wed, 16 May 2012 11:17:24 +0200
meillo@42 149 To: meillo
meillo@42 150 From: <meillo@dream.home.schnalke.org>
meillo@42 151 Subject: book
meillo@42 152
meillo@42 153 part text/plain 79
meillo@42 154 Hello meillo,
meillo@42 155
meillo@42 156 have a look at the ``Daemon book''. You need to read that!
meillo@42 157
meillo@42 158 foo
meillo@42 159
meillo@42 160 $ \f(CBrmm 1\fP
meillo@42 161
meillo@42 162 $ \f(CBscan\fP
meillo@42 163 2+ 2012-05-16 11:17 meillo@dream.home book
meillo@42 164
meillo@42 165 $
meillo@42 166 .DE
meillo@27 167
meillo@27 168
meillo@28 169 .H1 "nmh: Code and Community
meillo@2 170 .P
meillo@49 171 In order to understand the condition, goals and dynamics of a project,
meillo@49 172 one needs to know the reasons.
meillo@53 173 This section explains the background.
meillo@53 174 .P
meillo@49 175 MH predates the Internet, it comes from times before networking was universal,
meillo@49 176 it comes from times when emailing was small, short and simple.
meillo@42 177 Then it grew, spread and adopted to the changes email went through.
meillo@49 178 Its core-concepts, however, remained the same.
meillo@49 179 During the Eighties students at UCI actively worked on MH.
meillo@49 180 They added new features and optimized the code for the then popular systems.
meillo@49 181 All this still was in times before POSIX and ANSI C.
meillo@49 182 As large parts of the code stem from this time, today's nmh source code
meillo@49 183 still contains many ancient parts.
meillo@51 184 BSD-specific code and constructs tailored for hardware of that time
meillo@49 185 are frequent.
meillo@2 186 .P
meillo@49 187 Nmh started about a decade after the POSIX and ANSI C standards had been
meillo@49 188 established. A more modern coding style entered the code base, but still
meillo@49 189 a part of the developers came from ``the old days''. The developer
meillo@49 190 base became more diverse and thus resulted in code of different style.
meillo@49 191 Programming practices from different decades merged in the project.
meillo@51 192 As several peers added code, the system became more a conglomeration
meillo@51 193 of single tools rather than a homogeneous of-one-cast mail system.
meillo@49 194 Still, the existing basic concepts held it together.
meillo@8 195 They were mostly untouched throughout the years.
meillo@8 196 .P
meillo@51 197 Despite the tool chest approach at the surface \(en a collection
meillo@49 198 of separate small programs \(en on the source code level
meillo@49 199 it is much more interweaved.
meillo@49 200 Several separate components were compiled into one program
meillo@51 201 for efficiency reasons.
meillo@8 202 This lead to intricate innards.
meillo@49 203 Unfortunately, the clear separation on the outside appeared as being
meillo@49 204 pretty interweaved inside.
meillo@8 205 .P
meillo@49 206 The advent of MIME rose the complexity of email by a magnitude.
meillo@49 207 This is visible in nmh. The MIME-related parts are the most complex ones.
meillo@49 208 It's also visible that MIME support had been added on top of the old MH core.
meillo@51 209 MH's tool chest style made this easily possible and encourages
meillo@49 210 such approaches, but unfortunately, it lead to duplicated functions
meillo@49 211 and half-hearted implementation of the concepts.
meillo@49 212 .P
meillo@49 213 To provide backward-compatibility, it is a common understanding to not
meillo@49 214 change the default settings.
meillo@51 215 In consequence, the user needs to activate modern features explicitly
meillo@47 216 to be able to use them.
meillo@49 217 This puts a burden on new users, because out-of-the-box nmh remains
meillo@49 218 in the same ancient style.
meillo@49 219 If nmh is seen to be a back-end, then this compatibility surely is important.
meillo@49 220 However, in the same go, new users have difficulties to use nmh for modern
meillo@49 221 emailing.
meillo@49 222 The small but matured community around nmh hardly needs much change
meillo@49 223 as they have their convenient setups since decades.
meillo@8 224
meillo@8 225
meillo@27 226 .H1 "mmh
meillo@28 227 .P
meillo@49 228 I started to work on my experimental version in October 2011,
meillo@53 229 at a time when there were no more than three commits to nmh
meillo@53 230 since the beginning of the year.
meillo@53 231 In December, when I announced my work in progress on the
meillo@53 232 nmh-workers mailing list,
meillo@42 233 .[
meillo@51 234 nmh-workers mmh announce December
meillo@42 235 .]
meillo@53 236 nmh's community became active, too.
meillo@49 237 This movement was heavily pushed by Paul Vixie's ``edginess'' comment.
meillo@42 238 .[
meillo@42 239 nmh-workers vixie edginess
meillo@42 240 .]
meillo@53 241 After long years of stagnation, nmh became actively developed again.
meillo@42 242 Hence, while I was working on mmh, the community was working on nmh,
meillo@42 243 in parallel.
meillo@28 244 .P
meillo@53 245 The name \fImmh\fP may stand for \fImodern mail handler\fP,
meillo@53 246 because the project tries to modernize nmh.
meillo@53 247 Personally however, I prefer to call mmh \fImeillo's mail handler\fP,
meillo@53 248 emphasizing that the project follows my visions and preferences.
meillo@42 249 (My login name is \fImeillo\fP.)
meillo@53 250 This project model was inspired by \fIdwm\fP,
meillo@42 251 which is Anselm Garbe's personal window manager \(en
meillo@42 252 targeted to satisfy Garbe's personal needs whenever conflicts appear.
meillo@53 253 Dwm had retained its lean elegance and its focused character, whereas
meillo@53 254 its community-driven predecessor \fIwmii\fP had grown fat over time.
meillo@53 255 The development of mmh should remain focused.
meillo@27 256
meillo@45 257
meillo@27 258 .U2 "Motivation
meillo@27 259 .P
meillo@51 260 MH is the most important of very few command line tool chest email systems.
meillo@51 261 Tool chests are powerful because they can be perfectly automated and
meillo@53 262 extended. They allow arbitrary kinds of front-ends to be
meillo@53 263 implemented on top of them quickly and without internal knowledge.
meillo@53 264 Additionally, tool chests are much better to maintain than monolithic
meillo@43 265 programs.
meillo@53 266 As there are few tool chests for emailing and as MH-like ones are the most
meillo@53 267 popular among them they should be developed further.
meillo@53 268 This keeps their
meillo@43 269 conceptional elegance and unique scripting qualities available to users.
meillo@53 270 Mmh will create a modern and convenient entry point to MH-like systems
meillo@53 271 for new and interested users.
meillo@43 272 .P
meillo@51 273 The mmh project is motivated by deficits of nmh and
meillo@45 274 my wish for general changes, combined
meillo@45 275 with the nmh community's reluctancy to change.
meillo@45 276 .P
meillo@45 277 nmh hadn't adjusted to modern emailing needs well enough.
meillo@45 278 The default setup was completely unusable for modern emailing.
meillo@45 279 Too much setup work was required.
meillo@45 280 Several modern features were already available but the community
meillo@45 281 didn't wanted to have them as default.
meillo@45 282 mmh is a way to change this.
meillo@45 283 .P
meillo@45 284 In my eyes, MH's concepts could be exploited even better and
meillo@45 285 the style of the tools could be improved. Both would simplify
meillo@45 286 and generalize the system, providing cleaner interfaces and more
meillo@53 287 software leverage at the same time.
meillo@45 288 mmh is a way to demonstrate this.
meillo@45 289 .P
meillo@45 290 In providing several parts of an email system, nmh can hardly
meillo@45 291 compete with the large specialized projects that focus
meillo@45 292 on only one of the components.
meillo@45 293 The situation can be improved by concentrating the development power
meillo@51 294 on the most unique part of MH and letting the user pick his preferred
meillo@45 295 set of other mail components.
meillo@45 296 Today's pre-packaged software components encourage this model.
meillo@45 297 mmh is a way to go for this approach.
meillo@45 298 .P
meillo@43 299 It's worthwhile to fork nmh for the development of mmh, because
meillo@43 300 the two projects focus on different goals and differ in fundamental questions.
meillo@43 301 The nmh community's reluctance to change conflicts
meillo@43 302 with my strong will to change.
meillo@43 303 In developing a separate experimental version new approaches can
meillo@43 304 easily be tried out without the need to discuss changes beforehand.
meillo@43 305 In fact, revolutionary changes are hardly possible otherwise.
meillo@43 306 .P
meillo@45 307 The mmh project provides the basis to implemented and demonstrated
meillo@45 308 the listed ideas without the need to change nmh or its community.
meillo@43 309 Of course, the results of the mmh project shall improve nmh, in the end.
meillo@27 310
meillo@27 311 .U2 "Target Field
meillo@27 312 .P
meillo@45 313 Any effort needs to be targeted towards a specific goal
meillo@45 314 in order to be successful.
meillo@45 315 Following is a description of the imagined typical mmh user.
meillo@45 316 mmh should satisfy his needs.
meillo@53 317 .\" XXX Remove the next sentence?
meillo@48 318 Actually, as mmh is my personal version of MH, this is a description
meillo@48 319 of myself.
meillo@45 320 .P
meillo@43 321 The target user of mmh likes Unix and its philosophy.
meillo@27 322 He likes to use programs that are conceptionally appealing.
meillo@27 323 He's familiar with the command line and enjoys its power.
meillo@27 324 He is at least capable of shell scripting and wants to improve his
meillo@27 325 productivity by scripting the mail system.
meillo@43 326 He naturally uses modern email features, like attachments,
meillo@51 327 non-ASCII text, and digital cryptography.
meillo@43 328 He is able to setup email system components besides mmh,
meillo@51 329 and actually likes the choice to pick the ones he prefers.
meillo@43 330 He has a reasonably modern system that complies to standards,
meillo@43 331 like POSIX and ANSI C.
meillo@27 332 .P
meillo@48 333 The typical user invokes mmh commands directly in an interactive
meillo@48 334 shell session, but as well, he uses them to automate mail handling tasks.
meillo@48 335 Likely, he runs his mail setup on a server machine, to which he connects
meillo@48 336 via ssh. He might also have local mmh installations on his workstations,
meillo@51 337 but does rather not rely on graphical front-ends. He definitely wants
meillo@48 338 to be flexible and thus be able to change his setup to suite his needs.
meillo@8 339 .P
meillo@48 340 The typical mmh user is a programmer himself.
meillo@48 341 He likes to, occasionally, take the opportunity of Free Software to put
meillo@48 342 hands on and get involved in the software he uses.
meillo@48 343 Hence, he likes small and clean code bases and he cares for code quality.
meillo@48 344 In general, he believes that:
meillo@8 345 .BU
meillo@48 346 Elegance \(en i.e. simplicity, clarity and generality \(en
meillo@48 347 is most important.
meillo@8 348 .BU
meillo@48 349 Concepts are more important than the concrete implementation.
meillo@8 350 .BU
meillo@48 351 Code optimizations for anything but readability should be avoided
meillo@48 352 if possible.
meillo@8 353 .BU
meillo@45 354 Having a lot of choice is bad.
meillo@48 355 .BU
meillo@48 356 Removed code is debugged code.
meillo@8 357
meillo@48 358 .U2 "Goals
meillo@45 359 .P
meillo@45 360 The general goals for the mmh project are the following:
meillo@48 361 .IP "Stream-lining
meillo@48 362 Mmh should be stripped down to its core, which is the MUA part of emailing.
meillo@48 363 The feature set should be distilled to the ones really needed,
meillo@48 364 effectively removing corner-cases.
meillo@53 365 Parts that don't add to the main task of being a conceptionally
meillo@53 366 appealing MUA should be removed.
meillo@48 367 This includes, the MTA and MRA facilities.
meillo@48 368 Choice should be reduced to the main options.
meillo@48 369 .IP "Modernizing
meillo@48 370 Mmh's feature set needs to become more modern.
meillo@48 371 Better support for attachment and digital cryptography needs to be added.
meillo@48 372 MIME support needs to be integrated deeper and more naturally.
meillo@48 373 The modern email features need to be readily available, out-of-the-box.
meillo@48 374 And on the other hand,
meillo@48 375 bulletin board support and similar obsolete facilities need to be dropped
meillo@48 376 out.
meillo@48 377 Likewise, ancient technologies, like hardcopy terminals, should not
meillo@48 378 be supported any further.
meillo@48 379 .IP "Code style
meillo@48 380 Mmh's source code needs to be updated to modern standards.
meillo@48 381 Standardized library functions should replace non-standard versions
meillo@48 382 whenever possible.
meillo@48 383 Code should be separated into distinct modules when possible.
meillo@48 384 Time and space optimizations should to be replaced by
meillo@48 385 clear and readable code.
meillo@48 386 A uniform programming style should prevail.
meillo@51 387 .IP "Homogeneity
meillo@48 388 The available concepts need to be expanded as far as possible.
meillo@48 389 A small set of concepts should prevail thoroughly throughout the system.
meillo@48 390 The whole system should appear to be of-one-style.
meillo@48 391 It should feel like being cast as one.