Chris Garrigues [EMAIL PROTECTED] writes:
What was the date of the memo. I think we may need to celebrate mh's silver
anniversary.
--- Forwarded Message
Received: from truth.rand.org by rand.org; Tue, 17 Apr 90 09:03:40 -0700
Received: from localhost by truth.rand.org; Tue, 17 Apr 90 09:03:48 PDT
Message-Id: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], Robert_Anderson [EMAIL PROTECTED],
Phyllis_Kantar phyl@rcc, Tora_Bikson [EMAIL PROTECTED],
Willis_Ware [EMAIL PROTECTED]
Subject: The memo that began mh
Cc: Norman_Shapiro [EMAIL PROTECTED]
Date: Tue, 17 Apr 90 09:03:47 PDT
From: norm@truth
Attached is the result of rekeying a hardcopy of the memorandum.
An original softcopy is no longer available.
The rekeying attempted to duplicate the hardcopy including typos.
The hard copy was not dated, but is was sent sometime prior to February
17 1977 and probably sometime after January 17 1977.
To: Bob Anderson
From: Stock Gaines, Norm Shapiro
Subject: THE NEXT MESSAGE SYSTEM
Copies: Dave Crocker, Dave Farber, Carl Sunshine, Steve Tepper,
Steve Zucker
While the creators of MS are to be congratulated in having
produced a substantial advance over SND and MSG, the current
system, in a couple of ways, falls short of the software for
dealing with messages that we should have in UNIX. MS as it
stands is in two fundamental and important ways at odds with the
UNIX philosophy and approach. We think that another iteration on
message software should take place which will provide us with
software the dealing with messages that is again an advance over
MS and will fit in naturally with UNIX in a way that MS does not,
from which a number of practical advantages will follow. The two
ways in which MS is basically incompatible with the UNIX approach
are first that it is a monolithic system rather than being a set
of functions which are callible from wherever is appropriate, and
second that the storage of messages is not done by making
appropriate use of the file and directory structure (an
exceedingly elegant, simple and powerful one) already existing in
UNIX.
Let us discuss the UNIX way of storing messages first. As an
alternative to the clumsy method of using a text file and a
structure file, we suggest that instead a mailbox be simply a
directory. Each message would then be a separate file in that
directory. If it is necessary to keep additional information
about the files in the directory, that can be done by entering in
the message directory a file containing information about the
messages in the directory. Notice how many of the things we are
trying to do with the structure file get handled automatically if
this occurs. For instance, each time a message is written or
read, the file system already automatically updates this
information. Therefore, a clear indication that we have a new
message in a mail folder is that the instant of writing and
reading is the same. If they are different then we can test the
time last written to see if the message was received recently or
not. Dave Crocker has in the past pointed out that the rm
command has the disadvantage that it throws a file away. It
would be quite appropriate to add a shell command called, say,
dis (for discard) which moves a message from the directory it is
in to a subdirectory of that directory which we may think of as
the discarded messages directory. These messages can be cleaned
out by some sort of a cleanup command or by software that carries
out this task at appropriate times. The point is that IF the
garbage retrieval function is desireable for messages, then it is
so for files. Of course, in the directory structure we have no
information concerning the contents of messages. However, there
is some reason to be believe that the current design which
retains pointers to each of the components of a message is of no
advantage and may be more costly in execution time than if no
such information were available. In any event, it is merely an
effort towards efficiency and one which appears to have little
value.
The additional value which would accrue if messages were files is
substantial. They then become accessible to other software in
the system in a natural, convenient and highly useful way. The
lack of such accessibility of messages is currently one of the
major deficiencies of MS. As Steve Tepper has suggested, the
draft message might itself be a directory to expedite its
processing, although it is not clear that the advantages of this
outweigh the advantages of leaving the whole draft as a single
file.
The second major difference we are suggesting between the current
MS and the approach we believe is appropriate for UNIX is that
the functions for dealing with messages should be embodied in
individual command level routines which can be executed by
themselves rather than only being available through a subsystem.
The subsystem approach is appropriate for special situations such
as NED, but
