docs/unix-phil: unix-phil.ms comparison

comparison unix-phil.ms @ 20:578d5c84e5c0

a lot about mh (ch04)

author	meillo@marmaro.de
date	Fri, 26 Feb 2010 00:57:37 +0100
parents	d8f428cee0d1
children	ca929b042039

comparison

equal deleted inserted replaced

-:d8f428cee0d1
+:578d5c84e5c0
 %P Appendix B
 %O Also available online: \f(CW\s-2http://rand-mh.sourceforge.net/book/\fP
 .]
 .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,
+This might not be true,
-but it reflects the general situation pretty well.
+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.
 Following is a list of important programs of \s-1MH\s0's toolchest:
 .IP \(bu
 \f(CWshow\fP is like \f(CWcat\fP,
 \f(CWfolder\fP is like \f(CWcd\fP,
 \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,
+The current mail folder, similar to the current working directory,
-is maintained; \f(CWfolder\fP provides the functionality
+for which \f(CWfolder\fP provides the functionality of
-of \f(CWpwd\fP and \f(CWcd\fP for it.
+\f(CWpwd\fP and \f(CWcd\fP.
-A current message, relative to the current folder, is maintained.
+And the current message, relative to the current mail folder,
-This enables commands like \f(CWnext\fP and \f(CWprev\fP.
+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.
+But 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.
+which is mainly a legacy.
-But when multiple users want to work on one mail folder simultaneously,
+This will cause problems when multiple users work
-it will cause problems.
+in one mail folder simultaneously.
-This is a legacy from a time when emailing was different.
 .PP
 Using a monolithic program with a captive user interface
-means ``entering'' the program, using it, and ``leaving'' the program.
+means ``entering'' the program, using it, and ``exiting'' the program.
-Using a toolchest like \s-1MH\s0 means running programs,
+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
+.NH 2
-.LP
+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.
+but the frontend issues the appropriate calls when the user
-Providing easy-to-use user interfaces as frontends is a good
+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
+But if it is a separate program,
-at the backend directly.
+then the missing parts can still be accessed at the backend directly.
 If it is integrated, then this will hardly be possible.
-.PP
+.PP
+.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
-.PP
-easy to write: see ksh-book
-.NH 2
-Problems
-.LP
 .NH 1
 Case study: uzbl

Mercurial > docs > unix-phil

comparison unix-phil.ms @ 20:578d5c84e5c0