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

comparison unix-phil.ms @ 23:f0511a56416e

rework in ch04 and spell check

author	meillo@marmaro.de
date	Tue, 02 Mar 2010 14:34:07 +0100
parents	4c21f5b8d716
children	ec17b3a969c7

comparison

equal deleted inserted replaced

-:4c21f5b8d716
+:f0511a56416e
 .IP \(bu
 .I Efficiency
 (time behavior, resource utilization)
 .IP \(bu
 .I Maintainability
-(analysability, changeability, stability, testability)
+(analyzability, changeability, stability, testability)
 .IP \(bu
 .I Portability
 (adaptability, installability, co-existence, replaceability)
 .LP
 These goals are parts of a software's design.
 However, the Unix Philosophy has an \fIadditional\fP perspective on prototyping:
 After having built the prototype, one might notice, that the prototype is already
 \fIgood enough\fP.
 Hence, no reimplementation, in a more sophisticated programming language, might be of need,
 for the moment.
-Maybe later, it might be neccessary to rewrite the software, but not now.
+Maybe later, it might be necessary to rewrite the software, but not now.
 .PP
 By delaying further work, one keeps the flexibility to react easily on
 changing requirements.
 Software parts that are not written will not miss the requirements.
 and avoiding optimizations that introduce dependencies on specific hardware.
 Hardware has a much lower lifetime than software.
 By chaining software to a specific hardware,
 the software's lifetime gets shortened to that of this hardware.
 In contrast, software should be easy to port \(en
-adaption is the key to success.
+adaptation is the key to success.
 .\" cf. practice of prog: ch08
 .PP
 (2)
 .I "Portability of data
 is best achieved by avoiding binary representations
 to store data, because binary representations differ from machine to machine.
-Textual represenation is favored.
+Textual representation is favored.
 Historically, ASCII was the charset of choice.
 In the future, UTF-8 might be the better choice, however.
 Important is that it is a plain text representation in a
 very common charset encoding.
 Apart from being able to transfer data between machines,
 .\" gancarz tenet 5
 .PP
 (3)
 A large
 .I "range of usability
-ensures good adaption, and thus good survival.
+ensures good adaptation, and thus good survival.
 It is a special distinction if a software becomes used in fields of action,
 the original authors did never imagine.
 Software that solves problems in a general way will likely be used
 for all kinds of similar problems.
 Being too specific limits the range of uses.
 .NH 1
 Case study: \s-1MH\s0
 .LP
 The last chapter introduced and explained the Unix Philosophy
 from a general point of view.
-The driving force were the guidelines and 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-1MH\s0
+This first case study is about the mail user agents (\s-1MUA\s0)
-(``mail handler'') and its descendent \fInmh\fP (``new mail handler'').
+\s-1MH\s0 (``mail handler'') and its descendent \fInmh\fP
+(``new mail handler'').
+\s-1MUA\s0s provide functions to read, compose, and organize mail,
+but (ideally) not to transfer.
 In this document, the name \s-1MH\s0 will be used for both of them.
 A distinction will only be made if differences between
 them are described.
 .NH 2
 Historical background
 .LP
 Electronic mail was available in Unix very early.
-It is out of matter that in the beginning mail was only
-transferred within one machine.
-This chapter is about a mail user agent (\s-1MUA\s0),
-which provides functions to read, compose, and organize mail,
-but (ideally) not to transfer.
-.PP
 The first \s-1MUA\s0 on Unix was \f(CWmail\fP.
 It was a small program that either prints the own 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
 .]
 It was a program that did one job well.
-This job was emailing, which then was very simple.
+This job was emailing, which was very simple then.
 .PP
-Later, emailing became more powerfull, and thus more complex.
+Later, emailing became more powerful, and thus more complex.
 The simple \f(CWmail\fP, which knew nothing of subjects,
 independent handling of single messages,
 and long-time storage of them, was not powerful enough anymore.
 At Berkeley, Kurt Shoens wrote \fIMail\fP (with capital `M')
 in 1978 to provide additional functions for emailing.
 Mail was still one program, but now it was large and did
 several jobs.
-Its user interface is modeled after the one of ed.
+Its user interface is modeled after the one of \fIed\fP.
 It is designed for humans, but is still scriptable.
-\fImailx\fP is the adaption of Berkeley Mail into System V.
+\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
 followed Mail's direction.
 They are large, monolithic programs which include all emailing functions.
 .PP
-A different way took the people of \s-1RAND\s0 Corporation.
+A different way was taken by the people of \s-1RAND\s0 Corporation.
 In the beginning, they also had used a monolitic mail system,
-simply called \s-1MS\s0 for ``mail system''.
+called \s-1MS\s0 simply 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''.
 .PP
 Since then, \s-1RAND\s0, the University of California at Irvine and
 at Berkeley, and several others have contributed to the software.
 However, it's core concepts remained the same.
-In the 90s, when development of \s-1MH\s0 slowed down,
+In the late 90s, when development of \s-1MH\s0 slowed down,
 Richard Coleman started with \fInmh\fP, the new mail handler.
-This was in 1997.
 His goal was to improve \s-1MH\s0, especially in regard of
-the requirements of modern email.
+the requirements of modern emailing.
 Today, nmh is developed by various people on the Internet.
 .[
 %T RAND and the Information Evolution: A History in Essays and Vignettes
 %A Willis H. Ware
 %D 2008
 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.
-Following is a list of important programs of \s-1MH\s0's toolchest:
+Following is a list of important programs of \s-1MH\s0's toolchest
+and their function:
 .IP \(bu
 .CW inc :
 incorporate new mail
 .IP \(bu
 .CW scan :
 send a prepared message
 .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.
+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
 \s-1MH\s0's mail storage is (only little more than) a directory tree
-where directories are mail folders and files are mail messages.
+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(CWrefile\fP is like \f(CWmv\fP,
 and \f(CWrmm\fP is like \f(CWrm\fP.
 .PP
-The context of the Unix tools is mainly the current working directory,
+The context of tools in Unix is mainly the current working directory,
 the user identification, and the environment variables.
 \s-1MH\s0 extends this context by two more items:
-The current mail folder, similar to the current working directory,
+.IP \(bu
-for which \f(CWfolder\fP provides the functionality of
+The current mail folder, which is similar to the current working directory.
-\f(CWpwd\fP and \f(CWcd\fP.
+For mail folders, \f(CWfolder\fP provides the corresponding functionality
-And the current message, relative to the current mail folder,
+of \f(CWpwd\fP and \f(CWcd\fP for directories.
+.IP \(bu
+The current message, relative to the current mail folder,
 which enables commands like \f(CWnext\fP and \f(CWprev\fP.
+.LP
 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.
 But actually, the current message is a property of the mail folder,
-which is mainly a legacy.
+which appears to be 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 ``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
 Discussion of the design
 .LP
 The following paragraphs discuss \s-1MH\s0 in regard to the tenets
-of the Unix Philosophy Gancarz identified.
+of the Unix Philosophy which Gancarz identified.
 .PP
 .I "``Small is beautiful''
 and
 .I "``do one thing well''
 %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,
+to write, because each of them is small, limited to one function,
-and has clear bounderies.
+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 when \s-1MIME\s0 support was added
+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 nowhere available yet, he best takes a
+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
 (usually \f(CW$HOME/Mail\fP).
-Mail messages are text files located in a mail folder.
+Mail messages are text files located in mail folders.
 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.
 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
+because it is always necessary to first find and extract
 the relevant message in the mbox file.
-With \s-1MH\s0 mailboxes, each message is a self-standing item,
+With the \s-1MH\s0 mailbox format,
-by definition.
+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 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 anyway only be able to make a subset of the
-backend's power and flexibility available.
+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.
 .PP
 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
+Most of them comprise less than a hundred lines of shell code.
-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
+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
 possible, too.
 .PP
 create shell scripts that run a specific command line,
 build 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 prefere a different listing format for the \f(CWscan\fP
+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
 or to write one yourself.
 To use the format as default for \f(CWscan\fP, a single line,
 reading
 .CW
 scan: -form FORMATFILE
 .DE
 must be added to \f(CW.mh_profile\fP.
 If one wants this different format as an additional command,
-he needs to create a link to \f(CWscan\fP, for instance titled
+instead of changing the default, he needs to create a link to
-\f(CWscan2\fP.
+\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
 \f(CWscan2\fP.
 .PP
 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.
 \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.
 .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
 long time ago for \s-1MH\s0.
 But without following this guideline at the very beginning,
-Bruce Borden may have not convinced the management to ever
+Bruce Borden may have not convinced the management of \s-1RAND\s0
-create \s-1MH\s0.
+to ever create \s-1MH\s0.
-In Bruce's own words:
+In Bruce' own words:
 .QP
 [...] but [Stockton Gaines and Norm Shapiro] were not able
-to convince anyone that such a[n \s-1MH\s0-like] system
+to convince anyone that such a system would be fast enough to be usable.
-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,
 I built a working environment and some header files

Mercurial > docs > unix-phil

comparison unix-phil.ms @ 23:f0511a56416e