"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 inappropriate where there is not some overriding
consideration such as the consistency which must be maintained
between the different functions in a special environment. It is,
of course, desirable to maintain a certain amount of consistency
between the functions. Right now, for instance, it is nice (but
not critical) that MS remembers which message a user last
referred to, and will show the next message without his having to
remember what number to type next. However, there is a natural
and useful way of achieving that effect without a subsystem.
That is to have a "user environment" file available which the
message software (in contrast to a message system) knows about,
updates and understands. In such a user environment could
reasonably be a description of which message was last examined
and in which directory. This approach has the advantage that
such information is not lost, as it currently is when one exits
from MS.
It is quite evident how to implement most of the current MS
functions as individual subroutines. For instance, the scan
routine must examine a mailbox which is now a directory and
summarize the messages in it. This is nothing but an extension
of ls, which reads some information from the header of each
message in addition to reading the directory itself, and would be
very straightforward to implement. Reply clearly initializes the
draft message in a very straightforward way. The show command is
nothing but a variety of 1. Next and previous work in a
straightforward manner if user message environment file is
maintained.
There are other advangtages to this approach. Users who learn
Unix would not have to become familiar with a whole new language
but only with three or four new functions. As message handling
software evolves much of it will be applicable to other text
handling functions. For example, a program to display all
messages, in a given directory or set of directorys from, to or
about a given Unix user, would also be useable to display all
files in a "source" directory of c programs which use a given
function. Dually, as general Unix software evolves, it will tend
to be more applicable to message handling.
MS has made important contributions to our ideas concerning
messages and how to handle them. It is not the subsystem itself,
but the basic ideas about messages underlying it, which
represents the important contribution of its creators.It seems
likely that breaking the functions of MS out of a subsystem into
a set of separately executable subroutines would not be a
terribly difficult task, would give us an opportunity to redo
some of those in ways that correct some of the existing flaws,
and would integrate message handling into UNIX in a much more
natural and useful way. We suggest that this approach should be
followed in contrast to investing very much more effort into
upgrading MS.
We would be delighted to discuss these ideas more fully.
- ------- End of Forwarded Message
------- End of Forwarded Message
------- 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 inappropriate where there is not some overriding
consideration such as the consistency which must be maintained
between the different functions in a special environment. It is,
of course, desirable to maintain a certain amount of consistency
between the functions. Right now, for instance, it is nice (but
not critical) that MS remembers which message a user last
referred to, and will show the next message without his having to
remember what number to type next. However, there is a natural
and useful way of achieving that effect without a subsystem.
That is to have a "user environment" file available which the
message software (in contrast to a message system) knows about,
updates and understands. In such a user environment could
reasonably be a description of which message was last examined
and in which directory. This approach has the advantage that
such information is not lost, as it currently is when one exits
from MS.
It is quite evident how to implement most of the current MS
functions as individual subroutines. For instance, the scan
routine must examine a mailbox which is now a directory and
summarize the messages in it. This is nothing but an extension
of ls, which reads some information from the header of each
message in addition to reading the directory itself, and would be
very straightforward to implement. Reply clearly initializes the
draft message in a very straightforward way. The show command is
nothing but a variety of 1. Next and previous work in a
straightforward manner if user message environment file is
maintained.
There are other advangtages to this approach. Users who learn
Unix would not have to become familiar with a whole new language
but only with three or four new functions. As message handling
software evolves much of it will be applicable to other text
handling functions. For example, a program to display all
messages, in a given directory or set of directorys from, to or
about a given Unix user, would also be useable to display all
files in a "source" directory of c programs which use a given
function. Dually, as general Unix software evolves, it will tend
to be more applicable to message handling.
MS has made important contributions to our ideas concerning
messages and how to handle them. It is not the subsystem itself,
but the basic ideas about messages underlying it, which
represents the important contribution of its creators.It seems
likely that breaking the functions of MS out of a subsystem into
a set of separately executable subroutines would not be a
terribly difficult task, would give us an opportunity to redo
some of those in ways that correct some of the existing flaws,
and would integrate message handling into UNIX in a much more
natural and useful way. We suggest that this approach should be
followed in contrast to investing very much more effort into
upgrading MS.
We would be delighted to discuss these ideas more fully.
- ------- End of Forwarded Message
------- End of Forwarded Message
