docs/master

annotate intro.roff @ 227:157c92fc1597

Further improvements.
author markus schnalke <meillo@marmaro.de>
date Sun, 15 Jul 2012 23:44:15 +0200
parents 1fa5a74bf138
children a1468cf505fd
rev   line source
meillo@39 1 .RN 1
meillo@197 2 .H0 "Introduction
meillo@197 3 .Id introduction
meillo@39 4
meillo@0 5 .P
meillo@227 6 MH is a set of mail handling tools with a common concept.
meillo@227 7 It is similar to the Unix tool chest, which is a set of file
meillo@227 8 handling tools with a common concept.
meillo@227 9 \fInmh\fP is the currently most popular implementation of an
meillo@53 10 MH-like mail handling system.
meillo@53 11 This thesis describes an experimental version of nmh, named \fImmh\fP.
meillo@53 12 .P
meillo@32 13 This chapter introduces MH, its history, concepts and how it is used.
meillo@47 14 It describes nmh's code base and community to give the reader
meillo@227 15 a better understanding of the project's condition at the time when
meillo@227 16 mmh started off.
meillo@181 17 Furthermore, this chapter outlines the mmh project itself,
meillo@47 18 describing the motivation for it and its goals.
meillo@8 19
meillo@0 20
meillo@28 21 .H1 "MH \(en the Mail Handler
meillo@197 22 .Id mh
meillo@0 23 .P
meillo@47 24 MH is a conceptual email system design and its concrete implementation.
meillo@212 25 MH had started as a design proposal at RAND Corporation,
meillo@47 26 where the first implementation followed later.
meillo@47 27 In spirit, MH is similar to Unix, which
meillo@42 28 influenced the world more in being a set of system design concepts
meillo@32 29 than in being a specific software product.
meillo@47 30 The ideas behind Unix are summarized in the \fIUnix philosophy\fP.
meillo@207 31 .[
meillo@207 32 gancarz unix philosophy
meillo@207 33 .]
meillo@42 34 MH follows this philosophy.
meillo@2 35
meillo@11 36 .U2 "History
meillo@2 37 .P
meillo@32 38 In 1977 at RAND Corporation, Norman Shapiro and Stockton Gaines
meillo@209 39 proposed the design of a new mail handling system,
meillo@207 40 .[
meillo@207 41 shapiro gaines mh proposal
meillo@207 42 .]
meillo@209 43 to superseed RAND's old monolithic \fIMail System\fP (MS).
meillo@212 44 One year later, in 1978, Bruce Borden picked up on the
meillo@209 45 proposal and implemented a prototype, which he called
meillo@209 46 \fIMail Handler\fP (MH).
meillo@106 47 Before the prototype's existence, the concept was
meillo@47 48 believed to be practically unusable.
meillo@209 49 But the prototype \(en written in only three weeks \(en
meillo@212 50 proved successful and replaced MS thereafter.\&
meillo@209 51 .[ [
meillo@209 52 rand note design of mh
meillo@209 53 .], p. 4]
meillo@2 54 .P
meillo@106 55 In the early eighties,
meillo@106 56 the University of California at Irvine (UCI) started to use MH.
meillo@106 57 Marshall T. Rose and John L. Romine then became the driving force.
meillo@57 58 They took over the development and pushed MH forward.
meillo@209 59 .[ [
meillo@209 60 rand note design of mh
meillo@209 61 .], p. 4]
meillo@57 62 RAND had put the code into the public domain by then.
meillo@212 63 MH was developed at UCI at the same time when the Internet appeared,
meillo@212 64 BSD started to support TCP/IP networking,
meillo@209 65 and Eric Allman wrote Sendmail.
meillo@47 66 MH was extended as emailing became more featured.
meillo@209 67 The development of MH was closely related to the development of email RFCs.
meillo@204 68 In the advent of the \fIMultipurpose Internet Mail Extensions\fP (MIME),
meillo@204 69 MH was one of the first implementations of the new email standard.
meillo@2 70 .P
meillo@117 71 In the nineties, the Internet became popular and in December 1996,
meillo@181 72 Richard Coleman initiated the \fINew Mail Handler\fP (nmh) project.
meillo@212 73 Nmh is a fork of MH 6.8.3 and bases heavily on the
meillo@47 74 \fILBL changes\fP by Van Jacobson, Mike Karels and Craig Leres.
meillo@207 75 .[
meillo@207 76 lbl changes
meillo@207 77 .]
meillo@32 78 Colman intended to modernize MH and improve its portability and
meillo@32 79 MIME handling capabilities.
meillo@47 80 The development of MH at UCI stopped after the 6.8.4 release in
meillo@47 81 February 1996, soon after the development of nmh had started.
meillo@212 82 Today, nmh is developed openly in the Internet community.
meillo@212 83 It has almost completely replaced the original MH.
meillo@212 84 Some systems might still provide the old MH, but hardly for good reasons.
meillo@47 85 .P
meillo@212 86 In the last years, the majority of changes in nmh was maintenance work.
meillo@212 87 Nevertheless, the development was revived in December 2011
meillo@57 88 and stayed busy since then.
meillo@0 89
meillo@197 90
meillo@11 91 .U2 "Concepts
meillo@0 92 .P
meillo@53 93 MH consists of a set of tools, each covering a specific task of
meillo@209 94 email handling, such as composing a message, replying to a message,
meillo@53 95 refiling a message to a different folder, listing the messages in a folder.
meillo@209 96 The tools are invoked directly from the Unix shell.
meillo@209 97 .[
meillo@209 98 a rand note design of mh
meillo@209 99 .]
meillo@42 100 .P
meillo@209 101 The tools operate on a common mail storage, which consists of
meillo@209 102 \fImail folders\fP (directories) and \fPmessages\fP (regular files).
meillo@209 103 Each message is stored in a separate file.
meillo@209 104 .[
meillo@209 105 a rand note design of mh
meillo@209 106 .]
meillo@47 107 The files are named with ascending numbers in each folder.
meillo@47 108 The specific format of the mail storage characterizes MH in the same way
meillo@106 109 as the format of the file system characterizes Unix.
meillo@42 110 .P
meillo@164 111 MH tools maintain a \fIcontext\fP, which includes for instance the
meillo@164 112 current mail folder.
meillo@32 113 Processes in Unix have a similar context, containing the current working
meillo@32 114 directory, for instance. In contrast, the process context is maintained
meillo@32 115 by the Unix kernel automatically, whereas MH tools need to maintain the MH
meillo@32 116 context themselves.
meillo@106 117 The user can have one MH context or multiple ones; he can even share it
meillo@106 118 with others.
meillo@42 119 .P
meillo@164 120 Messages are named by their numeric filename,
meillo@207 121 but they can have symbolic names, as well.
meillo@207 122 These are either one of six system-controlled position names
meillo@208 123 and a shorthand for the range of all messages,
meillo@32 124 or user-settable group names for arbitrary sets of messages.
meillo@32 125 These names are called sequences.
meillo@207 126 Automatically updated position names exist for the
meillo@208 127 first, last, previous, next, current message, and for the number
meillo@208 128 one beyond the last message.
meillo@207 129 (In mmh, the names of these sequences are abbreviated to the
meillo@207 130 first character.)
meillo@207 131 User-definded sequences can be bound to the folder containing the
meillo@207 132 messages (\fIpublic sequences\fP) or to the user's context
meillo@207 133 (\fIprivate sequences\fP).
meillo@2 134 .P
meillo@207 135 The user's \fIprofile\fP is the file that contains his MH configuration.
meillo@47 136 Default switches for the individual tools can be specified to
meillo@47 137 adjust them to the user's personal preferences.
meillo@207 138 These switches will be automatically supplied whenever the specific
meillo@207 139 tool is invoked.
meillo@164 140 Additionally, a single command can be linked under different names
meillo@207 141 with different default values.
meillo@207 142 Form templates for new messages and replies, as well as format files
meillo@207 143 to adjust the output of tools are easily exchanged in the profile.
meillo@212 144 Almost every part of the system can be adjusted to personal preference.
meillo@42 145 .P
meillo@212 146 The whole system is well scriptable and extensible.
meillo@207 147 New MH tools are built out of or on top of existing ones quickly.
meillo@212 148 MH encourages the user to tailor, extend, and automate the system.
meillo@207 149 As the MH tool chest was modeled after the Unix tool chest, the
meillo@207 150 properties of the latter apply to the former as well.
meillo@102 151
meillo@102 152
meillo@102 153
meillo@54 154 .U2 "Using MH
meillo@53 155 .P
meillo@209 156 Many tutorials to using MH
meillo@209 157 .[
meillo@209 158 rose sweet mh tutorial
meillo@209 159 .]
meillo@209 160 .[
meillo@209 161 moss jackson user's guide for mh
meillo@209 162 .]
meillo@209 163 .[
meillo@209 164 hegardt mh for beginners
meillo@209 165 .]
meillo@212 166 are old, but still they teach the concepts and basics,
meillo@212 167 which remained unchanged.
meillo@212 168 Rose and Romine have written an excellent introduction on a more
meillo@212 169 technical level, with pointers to advanced usage.
meillo@209 170 .[
meillo@209 171 rose romine real work
meillo@209 172 .]
meillo@212 173 For a more recent document, it is strongly recommended to have
meillo@212 174 a look at the \fIMH Book\fP,
meillo@54 175 .[ [
meillo@54 176 peek mh book
meillo@54 177 .], Part II]
meillo@212 178 especially at its online version.
meillo@27 179 .P
meillo@212 180 Following here is a sample mail handling session with mmh.
meillo@212 181 Details might vary to MH and nmh but the look and feel is the same.
meillo@82 182
meillo@202 183 .so input/mh-session
meillo@27 184
meillo@27 185
meillo@131 186 .H1 "nmh
meillo@2 187 .P
meillo@49 188 In order to understand the condition, goals and dynamics of a project,
meillo@106 189 one needs to know the reasons behind them.
meillo@212 190 This section gives background information.
meillo@53 191 .P
meillo@197 192 MH predates the Internet;
meillo@212 193 it comes from times before networking was universal;
meillo@49 194 it comes from times when emailing was small, short and simple.
meillo@212 195 Then, MH grew, spread and adapted to the changes email went through.
meillo@212 196 Its core concepts, however, remained the same.
meillo@106 197 During the eighties, students at UCI actively worked on MH.
meillo@164 198 They added new features and optimized the code for the systems
meillo@164 199 popular at that time.
meillo@212 200 This was in times before POSIX and ANSI C.
meillo@49 201 As large parts of the code stem from this time, today's nmh source code
meillo@49 202 still contains many ancient parts.
meillo@51 203 BSD-specific code and constructs tailored for hardware of that time
meillo@49 204 are frequent.
meillo@2 205 .P
meillo@212 206 Nmh started about one decade after the POSIX and ANSI C standards were
meillo@212 207 released.
meillo@212 208 A more modern coding style entered the code base but still
meillo@212 209 a part of the developers were ``of the old type''.
meillo@212 210 The developer base became more diverse,
meillo@212 211 thus broadening the range of different coding styles.
meillo@49 212 Programming practices from different decades merged in the project.
meillo@51 213 As several peers added code, the system became more a conglomeration
meillo@51 214 of single tools rather than a homogeneous of-one-cast mail system.
meillo@212 215 For that, leadership would have been necessary.
meillo@212 216 Nevertheless, MH's basic concepts held the project together.
meillo@8 217 They were mostly untouched throughout the years.
meillo@8 218 .P
meillo@212 219 Though clearly separated on the surface
meillo@212 220 \(en as a collection of small, separate programs \(en
meillo@212 221 the source code turns out to be fairly interwoven.
meillo@212 222 Multiple separate components are compiled into a program
meillo@51 223 for efficiency reasons.
meillo@212 224 This leads to intricate innards.
meillo@8 225 .P
meillo@212 226 It is visible in nmh that
meillo@212 227 the advent of MIME raised the complexity of email by a magnitude.
meillo@212 228 The MIME-related parts are the most complex ones.
meillo@106 229 It is also visible that MIME support was added on top of the old MH core.
meillo@51 230 MH's tool chest style made this easily possible and encourages
meillo@106 231 such approaches, but unfortunately, it led to duplicated functions
meillo@212 232 and half-hearted implementation of concepts.
meillo@49 233 .P
meillo@212 234 To provide backward-compatibility, it is a common understanding
meillo@212 235 in the nmh community to not change the default settings.
meillo@212 236 In consequence, users need to activate modern features explicitly
meillo@47 237 to be able to use them.
meillo@212 238 The ancient style in which fresh nmh setups remain to appear
meillo@212 239 causes difficulties for new users, as modern email features require
meillo@212 240 additional configuration.
meillo@212 241 The small but mature community around nmh, however, needs little change
meillo@106 242 as they have had their convenient setups for decades.
meillo@8 243
meillo@8 244
meillo@27 245 .H1 "mmh
meillo@28 246 .P
meillo@49 247 I started to work on my experimental version in October 2011,
meillo@197 248 basing my work on nmh version \fInmh-1.3-dev\fP.
meillo@197 249 At that time no more than three commits were made to nmh
meillo@212 250 since the beginning of 2011, the latest one being
meillo@212 251 .Ci a01a41d031c796b526329a4170eb23f0ac93b949 ,
meillo@212 252 commited on 2011-04-13.
meillo@53 253 In December, when I announced my work in progress on the
meillo@53 254 nmh-workers mailing list,
meillo@42 255 .[
meillo@51 256 nmh-workers mmh announce December
meillo@42 257 .]
meillo@197 258 nmh's community became active, all of a sudden.
meillo@49 259 This movement was heavily pushed by Paul Vixie's ``edginess'' comment.
meillo@42 260 .[
meillo@42 261 nmh-workers vixie edginess
meillo@42 262 .]
meillo@53 263 After long years of stagnation, nmh became actively developed again.
meillo@197 264 Hence, while I was working on mmh, the community was working on nmh,
meillo@212 265 in parallel but unrelated.
meillo@28 266 .P
meillo@53 267 The name \fImmh\fP may stand for \fImodern mail handler\fP,
meillo@53 268 because the project tries to modernize nmh.
meillo@53 269 Personally however, I prefer to call mmh \fImeillo's mail handler\fP,
meillo@207 270 emphasizing that the project is my version of nmh,
meillo@207 271 following my visions and preferences.
meillo@42 272 (My login name is \fImeillo\fP.)
meillo@53 273 This project model was inspired by \fIdwm\fP,
meillo@42 274 which is Anselm Garbe's personal window manager \(en
meillo@42 275 targeted to satisfy Garbe's personal needs whenever conflicts appear.
meillo@227 276 Dwm has retained its lean elegance and its focused character,
meillo@227 277 .[
meillo@227 278 dwm ohloh
meillo@227 279 .]
meillo@227 280 whereas its community-driven predecessor \fIwmii\fP had grown
meillo@227 281 fat over time.
meillo@227 282 .[
meillo@227 283 wmii ohloh
meillo@227 284 .]
meillo@53 285 The development of mmh should remain focused.
meillo@27 286
meillo@45 287
meillo@27 288 .U2 "Motivation
meillo@27 289 .P
meillo@207 290 MH is the most important of very few email systems in a tool chest style.
meillo@51 291 Tool chests are powerful because they can be perfectly automated and
meillo@212 292 extended.
meillo@212 293 They allow the implementation of arbitrary kinds of front-ends
meillo@212 294 on top of the tool chest quickly and without internal knowledge.
meillo@106 295 Additionally, tool chests are easier to maintain than monolithic
meillo@43 296 programs.
meillo@227 297 .[ [
meillo@227 298 gancarz unix phil
meillo@227 299 .], p. 14]
meillo@212 300 MH-like email tool chests should be kept alive as they fill a market
meillo@212 301 niche by providing conceptional elegance and unique scripting qualities.
meillo@212 302 Mmh tries to create a modern and convenient entry point to MH-like
meillo@212 303 systems for new and interested users.
meillo@43 304 .P
meillo@51 305 The mmh project is motivated by deficits of nmh and
meillo@212 306 by my wish for general changes.
meillo@212 307 At the time the mmh project started, nmh had not yet adjusted to
meillo@212 308 modern emailing needs well enough.
meillo@45 309 The default setup was completely unusable for modern emailing.
meillo@45 310 Too much setup work was required.
meillo@212 311 Several modern features were already available,
meillo@212 312 but the community did not want to have them active by default.
meillo@212 313 Mmh is my way to change this.
meillo@45 314 .P
meillo@212 315 In my eyes, MH's concepts could be exploited better and
meillo@212 316 the style of the tools could be improved.
meillo@212 317 Both would simplify and generalize the system, providing cleaner
meillo@212 318 interfaces and greater software leverage at the same time.
meillo@212 319 Mmh is my way to demonstrate this.
meillo@45 320 .P
meillo@212 321 In providing multiple parts of the email system, nmh can hardly
meillo@45 322 compete with the large specialized projects that focus
meillo@212 323 on one of the components only.
meillo@212 324 The situation could be improved by concentrating the development power
meillo@51 325 on the most unique part of MH and letting the user pick his preferred
meillo@45 326 set of other mail components.
meillo@45 327 Today's pre-packaged software components encourage this model.
meillo@212 328 Mmh is my way to provide this.
meillo@45 329 .P
meillo@197 330 It is worthwhile to fork nmh for the development of mmh,
meillo@197 331 because the two projects focus on different goals and differ in
meillo@197 332 fundamental questions.
meillo@106 333 The nmh community's reluctance regarding change conflicts
meillo@106 334 with my strong desire for it.
meillo@207 335 .[
meillo@207 336 nmh-workers schnalke understanding nmh
meillo@207 337 .]
meillo@212 338 In developing a separate experimental version, new approaches can
meillo@43 339 easily be tried out without the need to discuss changes beforehand.
meillo@43 340 In fact, revolutionary changes are hardly possible otherwise.
meillo@43 341 .P
meillo@117 342 The mmh project provides the basis on which the aforementioned
meillo@117 343 ideas can be implemented and demonstrated,
meillo@164 344 without the need to change the nmh project or its community.
meillo@43 345 Of course, the results of the mmh project shall improve nmh, in the end.
meillo@159 346 By no means it is my intent to work against the nmh project.
meillo@117 347
meillo@27 348
meillo@27 349 .U2 "Target Field
meillo@27 350 .P
meillo@45 351 Any effort needs to be targeted towards a specific goal
meillo@45 352 in order to be successful.
meillo@197 353 Therefore, a description of an imagined typical mmh user follows.
meillo@212 354 Actually, as mmh is my personal version of MH,
meillo@212 355 this is sort of a description of myself.
meillo@212 356 Developing software for one's own is a reliable way to produce software
meillo@197 357 that matches the user's desires.
meillo@45 358 .P
meillo@197 359 The target user of mmh likes Unix and its philosophy.
meillo@197 360 He appreciates to use programs that are conceptionally appealing.
meillo@197 361 He is familiar with the command line and enjoys its power.
meillo@197 362 He is capable of shell scripting and wants to improve his
meillo@27 363 productivity by scripting the mail system.
meillo@197 364 He uses modern email features, such as attachments,
meillo@169 365 non-ASCII text, digital signatures and message encryption in a natural way.
meillo@212 366 He is able to set up mail system components
meillo@212 367 and likes to pick the ones he prefers.
meillo@197 368 He has a reasonably modern operating system that complies to the
meillo@164 369 POSIX and ANSI C standards.
meillo@27 370 .P
meillo@197 371 The typical user invokes mmh commands directly in an interactive
meillo@212 372 shell session, even on workstations where graphical front-ends could
meillo@212 373 be added.
meillo@197 374 Likely, he runs his mail setup on a server machine,
meillo@197 375 to which he connects via ssh.
meillo@212 376 He might automate mail processing with mmh tools
meillo@212 377 but definitely he uses the tools to build better tools.
meillo@212 378 In any case, he wants to have the flexibility to change
meillo@197 379 his setup to suit his needs.
meillo@8 380 .P
meillo@197 381 The typical mmh user is a programmer.
meillo@212 382 He likes to, occasionally, make use of the opportunity of free software
meillo@212 383 by putting hands on and getting involved in software he uses.
meillo@197 384 In consequence, he likes small and clean code bases and cares for
meillo@197 385 code quality.
meillo@197 386 In general, he believes that:
meillo@8 387 .BU
meillo@197 388 The elegance of source code is most important.
meillo@8 389 .BU
meillo@197 390 Concepts are more important than concrete implementations.
meillo@8 391 .BU
meillo@197 392 Code optimizations for anything but readability should be avoided.
meillo@8 393 .BU
meillo@212 394 Removed code is debugged code.
meillo@212 395 .BU
meillo@45 396 Having a lot of choice is bad.
meillo@8 397
meillo@197 398
meillo@212 399 .U2 "Goals of the mmh Project
meillo@128 400 .IP "Streamlining
meillo@87 401 Mmh should be stripped down to its core, which is the user agent (MUA).
meillo@117 402 The feature set should be distilled to the indispensable ones,
meillo@171 403 effectively removing corner cases.
meillo@173 404 Parts that do not add to the main task of being a conceptionally
meillo@187 405 appealing user agent should be removed.
meillo@212 406 This includes the mail transfer and mail retrieval facilities.
meillo@48 407 Choice should be reduced to the main options.
meillo@131 408 All tools should be tightly shaped.
meillo@48 409 .IP "Modernizing
meillo@48 410 Mmh's feature set needs to become more modern.
meillo@212 411 Better support for attachments, digital signatures, and message
meillo@212 412 encryption should be added.
meillo@159 413 MIME support should be integrated deeper and more naturally.
meillo@48 414 The modern email features need to be readily available, out-of-the-box.
meillo@212 415 On the other hand, obsolete facilities can be dropped out and
meillo@212 416 ancient technologies need not be further supported.
meillo@212 417 The available concepts should be expanded as far as possible.
meillo@131 418 A small set of concepts should recur consistently.
meillo@131 419 .IP "Styling
meillo@212 420 Mmh's source code should be updated to modern standards.
meillo@48 421 Standardized library functions should replace non-standard versions
meillo@48 422 whenever possible.
meillo@117 423 Code should be separated into distinct modules when feasible.
meillo@48 424 Time and space optimizations should to be replaced by
meillo@48 425 clear and readable code.
meillo@48 426 A uniform programming style should prevail.
meillo@117 427 The whole system should appear to be of-one-style;
meillo@117 428 it should feel like being cast as one.