# HG changeset patch # User meillo@marmaro.de # Date 1267142257 -3600 # Node ID 578d5c84e5c0ad00fea0028a4e14875ad68e3fae # Parent d8f428cee0d1988eb7c806464cc6716ba1226128 a lot about mh (ch04) diff -r d8f428cee0d1 -r 578d5c84e5c0 unix-phil.ms --- a/unix-phil.ms Thu Feb 25 15:06:34 2010 +0100 +++ b/unix-phil.ms Fri Feb 26 00:57:37 2010 +0100 @@ -745,11 +745,11 @@ .] .NH 2 -Contrasts to similar software +Contrasts to monolithic mail systems .LP All \s-1MUA\s0s are monolithic, except \s-1MH\s0. -This might not be completely true, -but it reflects the general situation pretty well. +This might not be true, +but it reflects the situation pretty well. .PP While monolithic \s-1MUA\s0s gather all function in one program, \s-1MH\s0 is a toolchest of many small tools \(en one for each job. @@ -801,56 +801,174 @@ \f(CWrefile\fP is like \f(CWmv\fP, and \f(CWrmm\fP is like \f(CWrm\fP. .PP -The most important difference to Unix' toolchest is, -that \s-1MH\s0's tools have an own context. The context of the Unix tools is mainly the current working directory, the user identification, and the environment variables. \s-1MH\s0 extends this context by two more items: -A current mail folder, similar to the current working directory, -is maintained; \f(CWfolder\fP provides the functionality -of \f(CWpwd\fP and \f(CWcd\fP for it. -A current message, relative to the current folder, is maintained. -This enables commands like \f(CWnext\fP and \f(CWprev\fP. +The current mail folder, similar to the current working directory, +for which \f(CWfolder\fP provides the functionality of +\f(CWpwd\fP and \f(CWcd\fP. +And the current message, relative to the current mail folder, +which enables commands like \f(CWnext\fP and \f(CWprev\fP. In contrast to Unix' context, which is chained to the shell session, \s-1MH\s0's context is meant to be chained to a mail account. -Actually, the current message is a property of the mail folder. -This is without problem as long as a mail folder belongs to one user. -But when multiple users want to work on one mail folder simultaneously, -it will cause problems. -This is a legacy from a time when emailing was different. +But actually, the current message is a property of the mail folder, +which is mainly a legacy. +This will cause problems when multiple users work +in one mail folder simultaneously. .PP Using a monolithic program with a captive user interface -means ``entering'' the program, using it, and ``leaving'' the program. -Using a toolchest like \s-1MH\s0 means running programs, +means ``entering'' the program, using it, and ``exiting'' the program. +Using toolchests like \s-1MH\s0 means running programs, alone or in combinition with others, even from other toolchests, without leaving the shell. + .NH 2 -Gains of the design +Discussion of the design .LP +The following paragraphs discuss \s-1MH\s0 in regard to the tenets +of the Unix Philosophy Gancarz identified. + +.PP +.I "``Small is beautiful'' +and +.I "``do one thing well'' +are two design goals that are directly visible in \s-1MH\s0. +Gancarz actually presents \s-1MH\s0 as example under the headline +``Making UNIX Do One Thing Well'': +.QP +[\s-1MH\s0] consists of a series of programs which +when combined give the user an enormous ability +to manipulate electronic mail messages. +A complex application, it shows that not only is it +possible to build large applications from smaller +components, but also that such designs are actually preferable. +.[ +%A Mike Gancarz +%T unix-phil +%P 125 +.] +.LP +The various small programs of \s-1MH\s0 were relatively easy +to write as each of them is small, limited to one function, +and has clear bounderies. +For the same reasons, they are also good to maintain. +Further more, the system can easily get extended. +One only needs to put a new program into the toolchest. +This was done when \s-1MIME\s0 support was added +(e.g. \f(CWmhbuild\fP). +Also, different programs can exist to do the basically same job +in different ways (e.g. in nmh: \f(CWshow\fP and \f(CWmhshow\fP). +If someone needs a mail system with some additionally +functions that are nowhere available yet, he best takes a +toolchest system like \s-1MH\s0 where he can add the +functionality with little work. + +.PP +.I "Data storage. +How \s-1MH\s0 stores data was already mentioned. +Mail folders are directories (which contain a file +\&\f(CW.mh_sequences\fP) under the user's \s-1MH\s0 directory +(usually \f(CW$HOME/Mail\fP). +Mail messages are text files located in a mail folder. +The files contain the messages as they were received. +The messages are numbered in ascending order in each folder. +This mailbox format is called ``\s-1MH\s0'' after the \s-1MUA\s0. +Alternatives are \fImbox\fP and \fImaildir\fP. +In the mbox format all messages are stored within one file. +This was a good solution in the early days, when messages +were only a few lines of text and were deleted soon. +Today, when single messages often include several megabytes +of attachments, it is a bad solution. +Another disadvantage of the mbox format is that it is +more difficult to write tools that work on mail messages, +because it is always neccessary to first find and extract +the relevant message in the mbox file. +With \s-1MH\s0 mailboxes, each message is a self-standing item, +by definition. +Also, the problem of concurrent access to one mailbox is +reduced to the problem of concurrent access to one message. +However, the issue of the shared parts of the context, +as mentioned above, remains. +Maildir is generally similar to \s-1MH\s0's format, +but modified towards guaranteed reliability. +This involves some complexity, unfortunately. + +.PP +.I "``Avoid captive user interfaces.'' \s-1MH\s0 is perfectly suited for non-interactive use. It offers all functions directly and without captive user interfaces. If users want a graphical user interface, anyhow, -they can have it with \fIxmh\fP or \fIexmh\fP. +they can have it with \fIxmh\fP or \fIexmh\fP, too. These are graphical frontends for the \s-1MH\s0 toolchest. This means, all email-related work is still done by \s-1MH\s0 tools, -but xmh issues the calls when the user clicks a button. -Providing easy-to-use user interfaces as frontends is a good +but the frontend issues the appropriate calls when the user +clicks on a button. +Providing easy-to-use user interfaces in form of frontends is a good approach, because it does not limit the power of the backend itself. -The frontend will anyways only be able to make a part of the +The frontend will anyway only be able to make a subset of the backend's power and flexibility available. -If it is separate, then the missing parts can still be accessed -at the backend directly. +But if it is a separate program, +then the missing parts can still be accessed at the backend directly. If it is integrated, then this will hardly be possible. -.PP -flexibility, no redundancy, use the shell .PP -easy to write: see ksh-book +.I "``Choose portability over efficiency'' +and +.I "``use shell scripts to increase leverage and portability'' . +These two tenets are indirectly, but nicely, demonstrated by +Bolsky and Korn in their book about the korn shell. +.[ +%T The KornShell: command and programming language +%A Morris I. Bolsky +%A David G. Korn +%I Prentice Hall +%D 1989 +%O \s-1ISBN\s0: 0-13-516972-0 +.] +They demonstrated, in one chapter of the book, a basic implementation +of a subset of \s-1MH\s0 in ksh scripts. +Of course, this was just a demonstration, but a brilliant one. +It shows how quickly one can implement such a prototype with shell scripts, +and how readable they are. +The implementation in the scripting language may not be very fast, +but it can be fast enough though, and this is all that matters. +By having the code in an interpreted language, like the shell, +portability becomes a minor issue, if we assume the interpreter +to be widespread. +This demonstration also shows how easy it is to create single programs +of a toolchest software. +Most of the single programs comprise less than a hundred lines of +shell code. +Such small software is easy to write, easy to understand, +and thus easy to maintain. +Being a toolchest improved the possibility to only write some parts +and though create a working result. +Expanding the toolchest without global changes will likely be +possible, too. + +.PP +.I "``Use software leverage to your advantage'' +and the lesser tenet +.I "``allow the user to tailor the environment'' +are ideally followed in the design of \s-1MH\s0. + +.PP +filters: many tools provide basic FS operations (like mv, rm, ...) +prototypes: affect dev, but MH is very matured .NH 2 Problems .LP +modern emailing +MIME +encodings +largest problem: different feeling + +.NH 2 +Summary \s-1MH\s0 +.LP +flexibility, no redundancy, use the shell