Shell
This may be provided by the user interface and is not in the basic system. It is listed in this specification as a reminder of its utility for most interactive systems. The user is given access to a version of the Shell program (see Figure 2).
Show (components) (msgs)
Displays messages at the user's terminal. "Components" defaults to the set stored in the user's Profile (initially, "Allf'). "Msgs" defaults to the current message. The last message in "msgsf' becomes the current message, if it is not the draft.
Statistics (name) (type) (value)
This function is not intended for the user; it is intended for standardized collection of user statistics, such as the names of functions that are called and the amount of computation which is required to perform particular functions. "Nameff is an identification name which is unique to the caller of this function. "Type" is a sub-grouping identifier; and "value" is any text to be taken as a piece of data for this statistic. The actual usage of this function will conform to legal and social privacy considerations.
Syntax (keyword)
Displays the syntax for the indicated command. This function is a subset of the Help function, printing only the "Syntax" portion of the associated online assistance message.
?
This function is not in the basic system; it is recommended for inclusion in most user interfaces. The feature causes a display of the list of inputs valid at that level of a specification. Therefore this function is not intended just for top-level use. It should be possible to invoke it in any argument.
IV. STATUS OF THE IMPLEMENTATION
MS became partially operational at Rand in the fall of 1976. The "ms", "msg", and "mail" interfaces are all used regularly by Rand staff members. Distribution of the system to other ARPA project Unix machines was begun in late summer 1977. By that time, almost all of the originally-specified functions were built. Only Annotate and Compare have not yet been implemented. More seriously, no portion of the Profile exists; its lack is felt by all users, in particular for the purposes of regularly viewing only portions of messages and setting several switches to redefine the system's default actions.
In addition, the system does not allow blind carbon copies of messages and does not strictly enforce constraints on modifying Sender, Message-ID, and Timestamp. While specifying message addresses, users cannot yet include the contents of lists in files (with "<") or direct a copy to a folder (with ">"); address list names also are not properly handled. Their lack has not been seriously felt by users, at this stage of system use. The online assistance capabilities have been implemented only partially; and the Scan listing measures message length in number of characters and not lines. Users are notified of new mail only when they initially log into Unix and, when using MS, upon Opening their inbox. In a few cases, more general message and component selection capabilities (e.g., full Boolean) would have proved useful.
Current activities involve exporting the system to other sites, adding the Profile and increasing the efficiency of the system code. Portions of MS are currently quite slow and this has deterred some users from the system. The focus of this optimization effort is the parallel "structure" file which was initially implemented in an extremely general organization. Experience with MS has suggested a more constrained organization. It should be noted that the presence of a dual-file organization makes the transition between structures quite simple.
V. CONCLUSIONS
Although MS has so far received only limited distribution, current indications are that it successfully fulfills its design goals. In particular, integrating access and modification capabilities with the draft and existing messages has proved extremely convenient. In general, the available functions and the style of their behaviors seem satisfactory to users, although the availability of the Profile would considerably improve some users' attitudes.
During the initial design review, the choice between using parallel files versus a single structured file led to some heated discussions. Experience to date thoroughly justifies the double-file choice, although its use did increase the complexity of the software needed to access and maintain text. The choice has meant that idiosyncratic, but necessary, modifications, such as massive reorganization to several messages, could be made to message files, without undue pain to the user.
The Map function has been a continuing problem. It has proved difficult to implement according to specifications and users are generally unable to employ it successfully. The Copy function is a direct result of these problems and it seems to adequately account for most users' needs, most of the time. It should be noted, however, that in at least one case a user wanted to copy a part of a message, into a draft component, and could not understand why the Copy function was unable to perform the function. This suggests that the focus on monolithicity is well-founded, and having the concept of the Map function has proved a useful focus for the MS project. In general, how- ever, such per-component manipulation is not currently needed, though this may change as the Profile enables users to specify complicated actions once and then repeatedly re-use the specification.
The Shell-syntax interface to MS has variously encouraged and deterred new users. Some indicate that the similarity of syntax did, in fact, facilitate their learning to use the system; others indicate that the inherent complexity of the full MS domain requires more effort than they wish to expend. These users are quite comfortable with the msg interface. A confounding factor is the system's slowness. Some users are waiting to make the transition to MS until after it has been made more efficient.
Implementing the basic system at the level of user-functions, rather than the more common primitive-functions, has also been a mixed blessing. User interfaces are, in fact, easier to build and the extra software overhead of placing the higher-level functions into the kernel of MS, appears to be minimal. However, the communication discipline between the user interface and MS kernel system is not wholly adequate. In particular, the user interface cannot query the kernel for status information (e.g., whether a message is discarded) and cannot adequately select subsets of different functions' behaviors. Also, the kernel's interactions with the user, such as for verification to performing some actions, cannot be fully controlled by the user interface. Remedies to these deficiencies are being considered.
From the standpoint of operational efficiency, it is unfortunately not currently possible to construct a simple system, with a subset of MS' full capabilities, without dragging along all of the software associated with the full system. The user need not see all of this, but it makes the programs more cumbersome. Some investigation is underway to discover how the system might be factored into smaller units; for example, infrequently-used functions, such as Cleanup, may be made separate processes.
Finally, use of the specification style led to a lack of precision in specifying the system's primitive functions. In some situations, this deficiency would have been disastrous. However, the project's operational environment made frequent consultation between members quite convenient. In addition, Bill Crosby, the system's primary implementor, usually chose to provide features in as general a fashion as possible; after experience was gained with the feature, tailoring it was usually quite simple. It should also be noted that much of the desired precision was not possible until we had that experience.
In spite of these problems, the specification style seems generally to have been useful, in that it has focused at the level of the user. Many systems, in spite of being examples of excellent software engineering, do not reflect this focus and are therefore inappropriate for most users.
Appendix A
SUMMARY OF FUNCTIONS
Add (component)
Sequential text is Copied from the user's terminal to the end of the named component in the draft.
Annotate (components) (msg)
Allows adding text to a message, while explicitly marking it as an addition to the original text. The integrity of the original message is thereby retained.
Cleanup
Causes discarded components and messages to be expunged from the message file.
Compose
Allows the user to conveniently A-dd to the "To" , "CC" , "Subject" , and "Body" components in Draft, by prompting for their text.
Copy (file) (component)
(msg) (component)
(msg) (folder)
Allows copying the contents of files, or existing messages, into a component of the draft message, and copying entire messages to other message files.
Correct (component)
Passes the named component through the Typo spelling corrector program.
Describe (keyword)
For obtaining information about the message system. A special file is searched for the keyword and the associated text is shown to the user.
Discard (msgs)
Marks the indicated messages as deleted from the mailbox.
Ed (component)
Invokes Ed editor with the contents of the named component.
File (msgs) (folder)
Moves the indicated messages to the end of the named file.
Format (component)
Passes the named components through the Nroff text formatting program.
Forward (msgs)
Packages up existing messages for retransmission to other mail receivers.
Goto (msg)
Changes the current message to the specified message.
Help (keyword)
Primitive help facility. A special text file will be searched for the indicated text and the user will be given the initial text associated with the keyword.
List (msgs) (order) (options) (file)
This is a primitive formatting function for producing hardcopy versions of messages.
Map
The generic text-transferring function, which is inconvenient to use for standard transfers. See @, Copy, and File function descriptions.
Ned (component)
Same as Ed function, but invokes the Ned two-dimensional CRT editor.
Next
Show the next message, relative to the current message.
Open (file)
Switches to another message file. When the system is first started, it defaults to opening the user's inbox.
Previous
Show the previous message, relative to the current message.
Process (component) (program)
Consecutively passes the named components through the named program. Correct uses Typo; Format uses Nroff.
Quit
Causes the mail system to stop and returns the user to the calling program (usually Shell).
Reply (msgs)
Allows responding to received messages.
Retrieve (msgs)
The complement of the Discard function.
Scan (msgs)
Scans the messages and produces a table of contents.
Send (preserve)
Packages up the draft message and submits it for transmission.
Show (msgs)
Displays the messages at the user's terminal.
Syntax (function)
Displays the syntax for the indicated function.
?
Displays a list of inputs valid at that level of a specification.
Appendix B
SAMPLE COMMAND INTERFACE
The sample command interface, specified here, is intended to be compatible with the syntax of the Unix Shell (see fig. 2); however, a few deviations are quite intentional.
In general, the user types the appropriate function name, to invoke a particular function. For convenience, the interface requires that only enough of the word be typed to distinguish it from other candidate names. For example "cop" means "copy". As an additional convenience, commands have a very terse form, which is shown immediately below the full form. A large number of synonyms have been defined for the commands and standard symbols, such as "examined". Users may type these synonyms, in place of the "official" terms, and they will be accepted, although they are not allowed to interfere with distinguishing between official terms. For example, "discarded" and "draft" are official terms referring to two different classes of messages; and "displayed" is a synonym for "seen". However, the user need type only "di" to mean "discarded" and must type at least "disp" to mean "displayed". The system is not so friendly as to advertise the synonyms it knows about. This limitation is imposed primarily to limit the length of listings produced with the ? function.
The system has a rudimentary error detection and correction facility appropriate to a line-oriented system. For example, upon detecting an error in part of a specification, the interface will notify the user of the nature of the error and prompt the user for the replacement information, saving all of the other information originally typed up to the point of the error. Except in the cases of folder and file names, the system will not make any distinction between upper and lower case characters in command lines.
The reader should remember that this interface is only one of several which are being implemented. It was the first interface built, in order to be compatible with the syntax of the existing Unix Shell, but is definitely not proffered as an example of a "friendly" human user interface. An MSG-type interface also is provided.
Defaults for function parameters are as recommended in the function descriptions. In addition, some abbreviated syntactic forms are allowed during specification; however, the interpretation of these depends upon context, as shown in the examples for the Copy Copy command, below. The "official" syntax, which conforms to Shell-syntax, does not have this dependency.
The system is invoked by typing "ms" to the Shell. A file name may be included as a parameter, in which case the indicated file, rather than the user's inbox, is opened.
The basic syntax for commands is:
command source -options > destination
where
command is the command word;
source is a filename or message/component specification;
options are optional switch settings; each option ("switch") is prefaced by a dash ("-");
destination is filename or message/component specification; ">" is required with destinations that are not defaulted
Specific command descriptions indicate limitations on the above. Also, for prompted input from the terminal, such as for the compose function, the user may enter only one line of text (unless the last character is backslash, as shown below), unless a message is displayed to the user indicating that a Control-D (the ASCII EOT character) at the beginning of a line will terminate input.
Other standards, where applicable:
\ (Backslash, when preceding a carriage-return) Continue onto next line.
I Passes the output to a process, rather than a file; in place of the ">" destination option.
--# Where appropriate, means to reverse the the meaning of the indicated (#) switch; for example, in the Format function, "-j" means to right-justify text, so "--j" means that justification will not occur.
# An integer, indicating a message's position within a mailbox.
#-# A sequence of messages, starting with the first message and ending with the last.
-c Following arguments are component references.
-f Following argument is a file reference.
-m Following arguments are message references.
x,x The same as two arguments separated by space.
c c Indicates a list of arguments, such as "to cc" or "3 4 7".
"..." A quoted parameter, which allows the text to contain special characters such as space.
For convenience, the "-m" , "-f" , and "-c" switches often are not necessary. If the specification is a common one, then the text typed by the user will be interpreted correctly. For example, the formal , specification for filing the current message into mailbox "filed.m" is "file -m current > -f filed.m"; however, the user actually need type only "f > filed.m"'.
Notational conventions, for the following descriptions:
c A single component may be referenced at this point;
cs Reference to a number of components is legal;
f Reference to a file is allowed;
m Reference to a single message is allowed;
ms Reference to a number of messages is allowed;
( ) Other information may be specified; the nature of this information is explained in the text of the associated description.
Commands
Add/A c
Annotate/An cs/ms [-e]
- e Following argument names text editor
Cleanup/Cl
Compare/Cpr c/m > c/m
Compose/C [-c] [-p]
-p Same as Preserve option, for Send
Copy/Cp f>c
ms > c [-n]
ms > f
-n Indicates that component names are to preface component text, when the second specification option is used.
Examples
Cp > backup .msg
Appends the current message to the end of file "backup.msg".
Cp -m 2 > -c Body
Adds message 2, as a block, to the end of the Body of the Draft. The "-m" is gratuitous, but the "-c" is not, since the destination of a message is usually a file.
Cp -f document > body
Appends the contents of file "document" to the end of the Body of the draft. The ">bodyw is gratuitous, since text copied from a file usually goes to the body of the draft. However, since the source of text is usually a message in the current mailbox, the "-f" specification is necessary.
Correct/Crct cs/m
Describe/Dsc (keyword)
Discard/D cs/m
Ed cs/m
File/F m>f
Format/Fm cs/ms [-j ]
- j Justify
Forward/Fw cs/ms [-p]
-p Preserve draft, as in Send
Goto/G m
Help/H (text)
List cs/ms [-h] [-pI [-s] ) f
-h Use next argument as page header;
-p Paginate within messages;
-s Separate messages; start each one on a new page;
Example
L 3-9 o0 memoform -p -h "Noteworthy Stuff" I 1pg Will list messages 3-9 on the printer; listing will be paginated with the indicated heading, and components will be ordered according to the list in the profile called Memoform. Messages will not begin on a new page.
Map f >cs/ms [-d]
cs/ms > cs/ms [-j] [-n]
cs/ms > f [-j] [-n]
-d Discard source version of text;
- j Turns on the join switch;
-n Indicates that component names are to preface component text, when the second specification option is used.
Examples
Map > backup.msg
Appends the current message to the end of file "backup.msg".
Map -c Subject -m 2,5,9 > -c Subject Keyword
Appends the text of the Subject components in messages 2, 5, and 9 to the Subject component and then the Keyword component of the draft.
Map -m 2 -c Subject,From CC To > -c Body
Adds the source components as a block to the end of the Body.
Map -m 2-5 -c From To CC BCC > -m 9
Adds the contents of each of the indicated address components onto components of the same name (creating them if they do not already exist) in message number 9.
Map -m 2-5 -c From To CC BCC > -m 9-10 -c From Subj
As when the text was copied to Body, above, the text is copied as a single group but to the end of the From and then the Subject components of messages 9 and then 10.
Map -m 2-5 -c From To,CC,BCC -n > -m 9-10 -c From Subj
Same as above, except that the text of each source component is prefaced by its component name.
Mark/Mk cs/ms (status)
Ned cs/ms
Next/N
Open/O f
Previous/P
Process/Prc cs/ms (program [-r]
-r replace each component with the output of the processing.
Quit/eot (control-D) and Q
Reply/Rpl ms [-a] [-i] [-p] [-v]
-a Author copy: Place "inbox" into fcc component.
-i Copy contents of the components, named in the following parameters, into the cc component of the draft.
-p Preserve, as with -Send.
-v Verify inclusion of each addressee.
Report/Rp
Retrieve/R cs/ms
Revise/Rv cs/ms [-e]
-e Following argument names editor
{ Scan } ms [ > f]
Scan/Sc ms [>f]
Send/Snd [-p] [-q] [-s]
-p Preserve Draft after sending.
-q Queue mail.
- s Send mail immediately.
Shell/Sh
Show/S cs/ms
Syntax/Sy (command)
?
Appendix C
NON-EXISTENT OR DISCARDED TEXT
During the initial phases of implementation, a question arose concerning the way in which MS should deal with user references to discarded or non-existent text. An exhaustive list of behaviors was created. It is included here because it represents a statement of philosophy concerning the treatment of user errors. What did the user probably mean? Some references are completely specific, in which case the user probably believes that the message is not discarded and therefore probably needs to be told, or when safe, the action should be performed. In other cases, an implicit reference is made, such as "examined", in which case the user probably does not care that a few I I extra" messages have been included; so the user is not burdened with the information that s/he has made an error.
In the following table,
Yes/No indicates whether the function is performed, or not;
Note/Quiet indicates whether a notice is displayed to user, or not;
Replace indicates whether discarded text is replaced; and
Flag indicates whether individual discarded messages are noted.
The Show function distinguishes between specific reference, as in "show 3" and implied reference, as in "show all".
Function / Component reference / Msg. reference
Add / Yes; quiet,replace / Not applicable
Comment / No; note / Not applicable
Copy -- See Map / --
Correct / No; note / Not applicable
Discard/ No; quiet / No; quiet
Ed/Re / Yes; replace / Not applicable
File / Not applicable / No; note
Format / No; note / Not applicable
Forward / No; note /Yes; quiet
Goto / Not applicable / Yes; Discard: quiet Not exist: note
List / No; quiet / no; note
Map / Srce: no; quiet Dest: note & replace / --
Next/Previous / Not applicable / Yes; discard: quiet not exist: note
Process / No; note / Not applicable
Reply / Not applicable / Yes; discard: quiet not exist: note
Retrieve / No; quiet / Yes; quiet
Revise / No; note / Not applicable
Scan / Not applicable / Yes; flag
Send / Not applicable / No; note
Show/implied / No; quiet / No; note
Show/specific / Yes; flag / Discard: yes, flag; Not exist: no; note
Appendix D
A COMMAND INTERFACE SCENARIO
REFERENCES
Anderson, R.H. and J.J. Gillogly, Rand Intelligent Terminal Agent (RITA): Design Philosophy, R-1809-ARPA, The Rand Corporation, Santa Monica, California, February 1976a.
Anderson, R.H. and J.J. Gillogly, "The RAND Intelligent Terminal Agent (RITA) as a Network Access Aid," Proceedings of the 1976 National Computer Conference, 1976b.
Bilofsky, W., The CRT Text Editor Ned: Introduction and Reference Manual. R-2176-ARPA. The Rand Corporation. Santa - Monica, California, in preparation, 1977.
Bobrow, D.G., J.D. Burchfiel, D.L. Murphy, and R.S. Tomlinson, TENEX, A Paged Time Sharing System for the PDP-10, BBN Report No. 2180, Bolt Beranek and Newman, Cambridge, 1971.
Broos, M.S., E.H. Black, and A. Vezza, MSGDMS Manual (draft), Laboratory for Computer Science, Massachusetts Institute of Technology, Cambridge, 1975.
Brown, T. and M. Klerer, "The Effect of Language Design on Time Sharing Operational Efficiency," International Journal of Man-Machine Studies, Vol. 7, 1975, pp. 233-247.
Carbonnel, J.R., J.E. Elkind, and R.S. Nickerson, "The Psychological Importance of Time in a Time Sharing System," Human Factors, Vol. 10, No. 2, 1968, pp. 135-142.
Carlisle, J.H. "Man-Computer Interactive Problem Solving: Relationship Between User Characteristics and Interface Complexity," Ph.D. Dissertation, NTIS No. AD786466, School of Organization and Management, Yale University, New Haven, June 1974.
Card, S.K., T.P. Moran and A. Newell, The Manuscript Editing Task: A_ Routine Cognitive Skill, PARC Report No. P76-00082, Xerox Systems Science Laboratory, Palo Alto Research Center, Palo Alto, California, 1977.
Crocker, S.D., J. Heafner, R. Metcalfe, and J. Postel, "Function-oriented Protocols for the ARPA Computer Network, Spring Joint Computer Conference, Vol. 40, 1972, pp. 271-279.
Engelbart, D.C., Coordinated Information Services Discipline- or Mission-Oriented Community, Network Information Center No. 12445, Augmentation Research Center, Stanford Research Institute, Palo Alto, California, 1972.
Heafner, J.H. "Design of Application-Oriented Languages by Protocol Analysis," Ph.D. Dissertation, University of Southern California, Los Angeles, 1976.
Heafner,' J.H. and L.H. Miller, Design Considerations for Computerized Message Service Based on Triservice Operations Personnel at CINCPAC Headquarters, Camp Smith, Oahu, ISI/WP-3, Information Sciences Institute, University of Southern California, Marina del Rey, California, September 1976.
Miller, George, "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information," Psychological Review, Vol. 63, 1956, 81-97.
Myer, T.H., J.R. Barnaby, and W.K. Plummer, TENEX Executive Language Manual for Users, Bolt Beranek and Newman, Cambridge, 1971.
Myer, T.H. and D.A. Henderson, "Message Transmission Protocol," Arpanet Request for Comments, No. 680, Network Information Center No. 32116; Augmentation Research Center, Stanford Research Institute, Menlo Park, California, 1975.
Myer, T.H. and C.D. Mooers, Hermes Users Guide, Bolt Beranek and Newman, Cambridge, 1976.
Panko, R., The Outlook for Computer Message Services: A Preliminar Assessment, Telecommunication Sciences Center, Stanford Research Institute, Palo Alto, California, March 1976.
Pogran, K., J. Vittal, A. Henderson, and D. Crocker, "Proposed Official Standard for the Format of ARPA Network Message Headers," Arpanet Request for Comments, No. 724, Network Information Center 37435; Augmentation Research Center, Stanford Research Institute, Menlo Park, California, May 1977.
Ritchie, D.M. and K. Thompson, "The UNIX Time-sharing System," Communications of the Association for Computing Machinery, Vol. 17, No. 7, July 1974, pp. 365-375.
Roberts, L. "Computer Network Development to Achieve Resource Sharing," Spring Joint Computer Conference, Vol. 36, 1970, pp. 543-549.
Thompson, K. and D.M. Ritchie, Unix Programmer's Manual, Bell Laboratories, Murray Hill, New Jersey, 1975.
Tugender, R. and D.R. Oestreicher, Basic Functional Capabilities for a Military Message Processing Service, Information Sciences Institute, Marina del Rey, California, 1975.
Uhlig, R., "Human Factors in Computer Message Systems," Datamation, Vol. 23, No. 5, May 1977, pp. 120-126.
Vezza, A., "A Model for an Electronic Postal System," In B.M. Owen (ed. ) , Telecommunications Policy Research conference Proceedings. Aspen Institute Program on Communications and Society, 360 Bryant St., Palo Alto, California 94301, 1976.
Vezza, A. and M.S. Broos, "An Electronic Message System: Where Does It Fit?" In Trends and Applications 1976: Computer Networks, Institute of Electrical and Electronic Engineers, New York, 1976.
Vittal, J. MSG Users Guide, Information Sciences Institute, University of Southern California, Los Angeles, 1975.
Walther, G.H., The Online User-Computer Interface: The Effects of Interface Flexibility, Experience, Terminal-Type on User Satisfaction and Performance, Ph.D. Dissertation, NTIS NO. AD777314, University of Texas, Austin, 1973.
Yntema, D.B. "Keeping Track of Several Things at Once," Human Factors, Vol. 5, 1963, 7-17.
Yntema, D.B. and G.E. Meuser, "Remembering the Present State of a Number of Variables," Journal of Experimental Psychology, Vol. 60, 1960, 18-22.
Yntema, D.B. and G.E. Meuser, "Keeping Track of Variables that Have Few of Many States," Journal of Experimental Psychology, Vo1.63, NO. 4, 1962, 391-395.
Yntema, D.B. and G.M. Schulman, "Response Selection in Keeping Track of -several Things at once;" Acts Psychologica, Vol. 27, 1967, pp. 316-324.
Yonke, M. BANANARD Users Guide, Information Sciences Institute, University of Southern California, Los Angeles, 1975.