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

comparison unix-phil.ms @ 30:ec17b3a969c7

various minor rework in ch04

author	meillo@marmaro.de
date	Wed, 24 Mar 2010 22:07:02 +0100
parents	f0511a56416e
children	0caa9760fca8

comparison

equal deleted inserted replaced

-:302daab2e8ee
+:ec17b3a969c7
 .NH 1
 Case study: \s-1MH\s0
 .LP
-The last chapter introduced and explained the Unix Philosophy
+The previous chapter introduced and explained the Unix Philosophy
 from a general point of view.
-The driving force were the guidelines, references to
+The driving force were the guidelines; references to
 existing software were given only sparsely.
 In this and the next chapter, concrete software will be
 the driving force in the discussion.
 .PP
 This first case study is about the mail user agents (\s-1MUA\s0)
 .NH 2
 Historical background
 .LP
 Electronic mail was available in Unix very early.
-The first \s-1MUA\s0 on Unix was \f(CWmail\fP.
+The first \s-1MUA\s0 on Unix was \f(CWmail\fP,
-It was a small program that either prints the own mailbox file
+which was already present in the First Edition.
+.[
+%A Peter H. Salus
+%T A Quarter Century of UNIX
+%D 1994
+%I Addison-Wesley
+%P 41 f.
+.]
+It was a small program that either prints the user's mailbox file
 or appends text to someone elses mailbox file,
 depending on the command line arguments.
 .[
 %O http://cm.bell-labs.com/cm/cs/who/dmr/pdfs/man12.pdf
 .]
 \fImailx\fP is the adaptation of Berkeley Mail into System V.
 .[
 %A Gunnar Ritter
 %O http://heirloom.sourceforge.net/mailx_history.html
 .]
-Elm, pine, mutt, and today a whole bunch of graphical \s-1MUA\s0s
+Elm, pine, mutt, and a whole bunch of graphical \s-1MUA\s0s
 followed Mail's direction.
 They are large, monolithic programs which include all emailing functions.
 .PP
 A different way was taken by the people of \s-1RAND\s0 Corporation.
 In the beginning, they also had used a monolitic mail system,
-called \s-1MS\s0 simply for ``mail system''.
+called \s-1MS\s0 (for ``mail system'').
 But in 1977, Stockton Gaines and Norman Shapiro
 came up with a proposal of a new email system concept \(en
 one that honors the Unix Philosophy.
 The concept was implemented by Bruce Borden in 1978 and 1979.
 This was the birth of \s-1MH\s0 \(en the ``mail handler''.
 .NH 2
 Contrasts to monolithic mail systems
 .LP
 All \s-1MUA\s0s are monolithic, except \s-1MH\s0.
-This might not be true,
+Although there might acutally exist further, very little known,
-but it reflects the situation pretty well.
+toolchest \s-1MUA\s0s, this statement reflects the situation pretty well.
 .PP
-While monolithic \s-1MUA\s0s gather all function in one program,
+Monolithic \s-1MUA\s0s gather all their functions in one program.
-\s-1MH\s0 is a toolchest of many small tools \(en one for each job.
+In contrast, \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
-and their function:
+and their function.
+It gives a feeling of how the toolchest looks like.
 .IP \(bu
 .CW inc :
-incorporate new mail
+incorporate new mail (this is how mail enters the system)
 .IP \(bu
 .CW scan :
 list messages in folder
 .IP \(bu
 .CW show :
 .IP \(bu
 .CW forw :
 forward a message
 .IP \(bu
 .CW send :
-send a prepared message
+send a prepared message (this is how mail leaves the system)
 .LP
 \s-1MH\s0 has no special user interface like monolithic \s-1MUA\s0s have.
 The user does not leave the shell to run \s-1MH\s0,
-but he uses \s-1MH\s0 within the shell.
+but he uses the various \s-1MH\s0 programs within the shell.
 Using a monolithic program with a captive user interface
 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.
-.PP
+.NH 2
+Data storage
+.LP
 \s-1MH\s0's mail storage is (only little more than) a directory tree
 where mail folders are directories and mail messages are text files.
 Working with \s-1MH\s0's toolchest is much like working
 with Unix' toolchest:
 \f(CWscan\fP is like \f(CWls\fP,
 \f(CWshow\fP is like \f(CWcat\fP,
-\f(CWfolder\fP is like \f(CWcd\fP,
+\f(CWfolder\fP is like \f(CWcd\fP/\f(CWpwd\fP,
 \f(CWrefile\fP is like \f(CWmv\fP,
 and \f(CWrmm\fP is like \f(CWrm\fP.
 .PP
 The context of tools in Unix is mainly the current working directory,
 the user identification, and the environment variables.
 \s-1MH\s0's context is meant to be chained to a mail account.
 But actually, the current message is a property of the mail folder,
 which appears to be a legacy.
 This will cause problems when multiple users work
 in one mail folder simultaneously.
-.NH 2
-Discussion of the design
-.LP
-The following paragraphs discuss \s-1MH\s0 in regard to the tenets
-of the Unix Philosophy which 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, because each of them is small, limited to one function,
-and has clear boundaries.
-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, for instance, 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 available nowhere 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
 as mentioned above, remains.
 Maildir is generally similar to \s-1MH\s0's format,
 but modified towards guaranteed reliability.
 This involves some complexity, unfortunately.
+.NH 2
+Discussion of the design
+.LP
+The following paragraphs discuss \s-1MH\s0 in regard to the tenets
+of the Unix Philosophy which 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, because each of them is small, limited to one function,
+and has clear boundaries.
+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, for instance, 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 available nowhere yet, he best takes a
+toolchest system like \s-1MH\s0 where he can add the
+functionality with little work.
+.PP
+.I "Store data in flat text files.
+FIXME
 .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,
+If, nonetheless, users want a graphical user interface,
 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 the frontend issues the appropriate calls when the user
-clicks on a button.
+clicks on buttons.
 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 anyway only be able to make a subset of the
 backend's power and flexibility available to the user.
 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.
+Further more, it is possible to have different frontends to the same
+backend.
 .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.
+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
+%P 254\(en290
 %O \s-1ISBN\s0: 0-13-516972-0
 .]
-They demonstrated, in one chapter of the book, a basic implementation
+They demonstrated, in chapter 18 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,
 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 them comprise less than a hundred lines of shell code.
+There are eight tools (two of them have multiple names) and 16 functions
+with supporting code.
+Each tool comprises between 12 and 38 lines of ksh,
+in total about 200 lines.
+The functions comprise between 3 and 78 lines of ksh,
+in total about 450 lines.
 Such small software is easy to write, easy to understand,
 and thus easy to maintain.
 A toolchest improves the possibility to only write some parts
 and though create a working result.
 Expanding the toolchest without global changes will likely be
 .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.
 Tailoring the environment is heavily encouraged by the ability to
-directly define default options to programs, even different ones
+directly define default options to programs.
+It is even possible to define different default options
 depending on the name under which the program was called.
 Software leverage is heavily encouraged by the ease it is to
 create shell scripts that run a specific command line,
-build of several \s-1MH\s0 programs.
+built of several \s-1MH\s0 programs.
 There is few software that so much wants users to tailor their
 environment and to leverage the use of the software, like \s-1MH\s0.
 Just to make one example:
 One might prefer a different listing format for the \f(CWscan\fP
 program.
-It is possible to take one of the other distributed format files
+It is possible to take one of the distributed format files
 or to write one yourself.
 To use the format as default for \f(CWscan\fP, a single line,
 reading
 .DS
 .CW
 must be added to \f(CW.mh_profile\fP.
 If one wants this different format as an additional command,
 instead of changing the default, he needs to create a link to
 \f(CWscan\fP, for instance titled \f(CWscan2\fP.
 The line in \f(CW.mh_profile\fP would then start with \f(CWscan2\fP,
-as the option should only be in effect when scan was called as
+as the option should only be in effect when scan is called as
 \f(CWscan2\fP.
 .PP
 .I "``Make every program a filter''
 is hard to find in \s-1MH\s0.
 The reason therefore is that most of \s-1MH\s0's tools provide
 basic file system operations for the mailboxes.
+The reason is the same because of which
 \f(CWls\fP, \f(CWcp\fP, \f(CWmv\fP, and \f(CWrm\fP
 aren't filters neither.
 However, they build a basis on which filters can operate.
 \s-1MH\s0 does not provide many filters itself, but it is a basis
 to write filters for.
+An example would be a mail message text highlighter,
+that means a program that makes use of a color terminal to display
+header lines, quotations, and signatures in distinct colors.
+The author's version of this program, for instance,
+is a 25 line awk script.
 .PP
 .I "``Build a prototype as soon as possible''
 was again well followed by \s-1MH\s0.
 This tenet, of course, focuses on early development, which is
 But without following this guideline at the very beginning,
 Bruce Borden may have not convinced the management of \s-1RAND\s0
 to ever create \s-1MH\s0.
 In Bruce' own words:
 .QP
-[...] but [Stockton Gaines and Norm Shapiro] were not able
+[...] but they [Stockton Gaines and Norm Shapiro] were not able
 to convince anyone that such a system would be fast enough to be usable.
 I proposed a very short project to prove the basic concepts,
 and my management agreed.
 Looking back, I realize that I had been very lucky with my first design.
 Without nearly enough design work,
 .NH 2
 Problems
 .LP
 \s-1MH\s0, for sure is not without problems.
-There are two main problems: one technical, the other about human behavior.
+There are two main problems: one is technical, the other is about human behavior.
 .PP
 \s-1MH\s0 is old and email today is very different to email in the time
 when \s-1MH\s0 was designed.
 \s-1MH\s0 adopted to the changes pretty well, but it is limited.
 For example in development resources.
 More active developers could quickly improve there.
 It is also limited by design, which is the larger problem.
 \s-1IMAP\s0, for example, conflicts with \s-1MH\s0's design to a large extend.
 These design conflicts are not easily solvable.
 Possibly, they require a redesign.
+Maybe \s-1IMAP\s0 is too different to the classic mail model which \s-1MH\s0 covers,
+hence \s-1MH\s0 may never work well with \s-1IMAP\s0.
 .PP
 The other kind of problem is human habits.
 When in this world almost all \s-1MUA\s0s are monolithic,
 it is very difficult to convince people to use a toolbox style \s-1MUA\s0
 like \s-1MH\s0.
 The habits are so strong, that even people who understood the concept
-and advantages of \s-1MH\s0 do not like to switch.
+and advantages of \s-1MH\s0 do not like to switch,
-Unfortunately, the frontends to \s-1MH\s0, which can provide familiar look'n'feel,
+simply because \s-1MH\s0 is different.
-are not very appealing in contrast to what monolithic \s-1MUA\s0s offer.
+Unfortunately, the frontends to \s-1MH\s0, which could provide familiar look'n'feel,
+are quite outdated and thus not very appealing compared to the modern interfaces
+which monolithic \s-1MUA\s0s offer.
 .NH 2
 Summary \s-1MH\s0
 .LP
 flexibility, no redundancy, use the shell

Mercurial > docs > unix-phil

comparison unix-phil.ms @ 30:ec17b3a969c7