text.tex

早期freebsd实现

% begin text

\banner

\section{Introduction}				% mtr
\tagfigure{0}{\MTS/ model}{mtsmodel}

The UCI version of the Rand Message Handling System, \MH/,
is a user agent.
In the interests of brevity,
we dispense with the usual definition of terms,
refer the reader to Figure~\mtsmodel,
and simply note that \MH/ is not responsible for delivering mail.
Rather,
it interacts with a {\it message transport system}, \MTS/,
at two interfaces:
it sends mail by placing it through a {\it posting slot} to the \MTS/,
and it receives mail by retrieving it through a {\it delivery slot} from the
\MTS/.
Besides these two \MTS/-specific activities,
the tasks which \MH/ addresses are:
the composition of messages
(which may, or may not, be in reference to previously sent messages),
the reading of messages,
and the organization of messages.

\MH/ was originally developed by the Rand Corporation,
and initially was proprietary software.
The Department of Information and Computer Science at
University of California, Irvine,
shortly after joining the Computer Science Network (CSnet),
acquired a copy of \MH/,
and began additional development of the software.
Since that time,
the Rand Corporation has declared \MH/ to be in the public domain,
and the UCI version of \MH/ has passed through four major releases.

Much credit must be given to the initial designers and implementors of \MH/:
Bruce Borden, Stockton Gaines, and Norman Shapiro.
Although \MH/ has suffered significant development at UCI
since Rand's initial release,
the fundamental concepts of \MH/'s environs have remained nearly unchanged.
In addition,
the current maintainers of \MH/ gratefully acknowledge the comments of the
many sites which have run various releases of \MH/ in the past.

\MH/ runs on different versions of the \unix/ operating system
(such as 4.2\bsd/~\unix/ and various flavors of v7~\unix/).
In addition,
\MH/ supports four different \MTS/ interfaces:
\SendMail/\cite{EAllm83},
the standard mailer for 4.2\bsd/ systems;
\MMDF/\cite{DCroc79} and \MMDFII/\cite{DKing84},
the Multi-Channel Memo Distribution Facility developed by the University of
Delaware
which forms the software-backbone for CSnet\cite{DCome83} mail relays service;
SMTP,
the ARPA Internet Simple Mail Transfer Protocol\cite{SMTP};
and,
a stand-alone delivery system.

The organization of this paper is straight-forward,
given space considerations.
Initially,
the \MH/ philosophy of mail handling is presented,
along with a description of the environment which the \MH/ user is given to
process mail.
Following this,
certain advanced features of \MH/ are discussed in more detail.
In particular,
the notion of a {\it draft folder} is introduced,
which permits the handling of multiple drafts during composition.
In addition,
message selection facilities are described.
Next,
two different aspects of \MH/'s power as a software system are discussed:
record handling, in which \MH/ facilitates record processing systems;
and,
how \MH/ can be employed in a distributed mail environment.
This latter section raises questions as to the location of the posting and
delivery slots,
along with authentication mechanisms.
Finally,
we conclude by discussing areas of future development which \MH/ may endure.

Although familiarity with \MH/ is not assumed on the part of the reader,
some knowledge of the \unix/ operating system is useful.
Appendix~A gives a short synopsis of the \MH/ commands.

\section{The \MH/ Philosophy}			% mtr
Although \MH/ has many traits which tend to differ it from other user agents,
the design aspect which fundamentally influences the interface between \MH/
and the user is that it is composed of many small
programs instead of one very large one.
This architecture gives \MH/ much of its strength,
since intermediate and advanced users are able to take advantage of this
flexibility.

The key to this flexibility is that the \unix/ shell
(usually the {\it C} shell or the {\it Bourne} shell),
is the user's interface to \MH/.
This means that when handling mail,
the entire power of the shell is at the user's disposal in addition to the
facilities which \MH/ provides.
Hence,
the user may intersperse mail handling commands with other commands in an
arbitrary fashion,
making use of command handling capabilities that the user's shell provides.

Furthermore,
rather than storing messages in a complicated data structure
within a monolithic file,
in \MH/, each message is a \unix/ file,
and each folder (an object which holds groups of messages)
is a \unix/ directory.
That is,
the directory and file structure of \unix/ is used directly.
As a result,
any \unix/ file-handling command can be applied to any message.

To the novice,
this may not make much sense or may not seem important.
From three years of observation, we have seen that
as users of \MH/ have become more experienced
they have found this capability to be quite attractive.
In addition,
this approach is often quite pleasing to system implementors,
because it minimizes the amount of coding to be performed
and,
given a modular design,
changes to the software system can be maintained easily.
Our empirical findings confirm our theoretical expectations regarding the
\MH/ architecture.

Having described how \MH/ fits into the \unix/ environment,
we now discuss the mail handling environment which is available to the \MH/
user.

\subsection{The \MH/ Environs}			% jns
\MH/ provides a complementary environment to the user's shell.
While the shell maintains a context related to the user's focus in the file
system (a {\it current working directory\/}),
mail handling is performed in a separate mail folder context.
Operations on mail can therefore be
performed entirely without regard to the current file system context,
although \MH/ does not prevent the user from making use of that context.
Certain mail handling functions do make use of information
maintained by the shell.
For instance, by setting certain shell parameters,
called {\it environment variables},
alternate mail handling contexts can be selected.

\MH/ conventions often have direct analogs to shell or file system
conventions.
The shell has a current working directory; \MH/ has a current mail folder.
When the user begins a session on the system,
the user's ``home directory'' is the base context;
\MH/'s default base area, the \Mail/ directory, 
is found under the user's home directory.
The user's default shell parameters are set upon beginning a new
session from a startup profile
(called \file{.profile} for \pgm{sh} users
or \file{.cshrc} for \pgm{csh} users);
the default parameters for \MH/ commands are taken from a file called
\profile/ in the user's home directory.
The shell has an {\it environment\/};
\MH/ has a \context/ file.
Each of the user's directories has files;
each of the user's \MH/ folders has messages.

These parallels have a basis not only in \MH/'s high level mail
handling model,
but also in the way low level shell and file
system conventions have been abstracted to implement \MH/ conventions.
Directories are folders; files are messages.
The \Mail/ directory forms the root of a virtual file subsystem within
which the user operates on mail without disturbing files outside this
mail handling domain. 

\tagfigure{1}{\MH/ File Subsystem\\(directories are shaded)}{MHfiles}
\tagdiagram{2}{Elaborated \MH/ Profile}{elab}
\subsection{The \MH/ Profile}
The \profile/ contains plaintext that describes the user's default mail
handling parameters.
An example of an elaborated profile is shown in Figure~\elab.

Each line in the profile consists of an \MH/ parameter name terminated
with a colon (`:') followed by parameter values.
In this example,
``global'' parameters are listed in the first few lines,
with program-specific parameters following.
Each \MH/ program examines global parameters as well as any parameter
with the same name by which the program was invoked.
For example,
the \pgm{comp} program, which is used to compose new messages to be sent,
examines the entries:
\medskip
{\advance\leftskip by2\parindent
\uitem{Path}
The path parameter specifies the name of the \MH/ root directory.
This is normally named \Mail/.

\uitem{Editor}
The editor parameter specifies which text editor is first invoked to create
the header information and body of a message draft.
In most cases, this editor is the \MH/ default editor, \pgm{prompter}.

\uitem{Draft-Folder}
This parameter specifies a folder within which new message drafts
are to be created.
The draft folder mechanism is an advanced feature of \MH/ that is
given separate treatment in a later segment of this paper.

\uitem{comp}
The program-specific parameter examined by \pgm{comp} lists
user-default options.
\par}
\medskip

\noindent
Other programs invoked by \pgm{comp}
(e.g. \pgm{prompter} and \pgm{send\/}) would examine their own profile 
entries as well.
\MH/ programs have reasonable compiled-in defaults and also permit options to
be specified on the shell command line with which the programs are invoked.
The order of override precedence is: command line options first,
\profile/ options second, and compiled-in defaults last.

Each program option is prefixed by a dash (`-') following the \unix/
convention.
Unlike most \unix/-style options,
however, the options are words rather than single letters.
An option may be abbreviated to an unambiguous prefix.
Each \MH/ program has a \switch{help} option that
displays a brief summary of the program's available options.

\subsection{Folders and Messages}
In a typical paper-oriented office,
new correspondence arrives and is stacked in an ``in box'',
while outgoing correspondence is placed in an ``out box''.
Processed material is stored in
appropriately labelled folders and filed away for future reference.
This state of affairs is modelled in \MH/ with {\it folders}
and {\it messages},
which are simply text files (one message per file) stored
under the folder directories.
Most of the user's folders are kept under the \Mail/ directory.

A folder is given an alphanumeric name permissible within the \unix/ file
system structure,
and each message stored therein is given a numeric name in the range 1..1999.
The upper bound on message numbers was
selected for efficient access to an internal representation,
an array of bits (a ``bit set''),
with each bit indicating the presence or
absence of a message with a number in the range 1..1999.
This internal representation also restricts the order of multiple
message reference to an ascending numerical sequence.
Other representations have been studied
(e.g., an unsorted sparse array of integers),
but have been rejected for reasons of efficiency.
Folders may contain subfolders,
corresponding to \unix/ tree-structured directories.
For the sake of completeness,
it might be said that ``sub-messages'' exist insofar as message ``digests'',
which nest messages inside other messages,
are supported by certain advanced \MH/ functions.

The current working folder is the default folder selected for almost
all \MH/ commands.
To select explicitly a folder for mail handling
commands entails specifying the name of the folder, prefixing the name
with a plus-symbol (`+').
An example is: \example refile\ 1\ 2\ 3\ +chron/yr.1984\endexample
This command re-files the selected messages
(\file{1}, \file{2}, and \file{3} here)
from the current working folder to a subfolder under the
folder \file{chron} named \file{yr.1984}.
To see the folder/subfolder relationship, refer to Figure~\MHfiles.