\begindata{text,539484024}
\textdsversion{12}
\template{default}
\define{global
}
\define{null
menu:[null]}
\define{itemize
menu:[Region,Itemize]
attr:[LeftMargin LeftMargin Inch 32768]}
\define{notetotypesetter
menu:[Region,NoteToTypesetter]
attr:[Flags PassThru Int Set]}
\define{p
menu:[Other,P]
attr:[FontFace Bold Int Set]}
\chapter{1	The Andrew Message System:

A Portable, Distributed System 

for Multi-Media Electronic Communication}


Nathaniel Borenstein

Craig Everhart

Jonathan Rosenbertg


\section{1.1	Introduction}


The Andrew Message System (AMS) is a project with the goal of producing a 
production-quality electronic communication environment with several types of 
functionality which have hitherto either not been provided by electronic 
message systems or have been found only in experimental systems.  The primary 
contributions of the AMS are: 


\itemize{\p{Machine and location independence}:  Users of the AMS can read 
mail or bulletin boards once on an advanced workstation (Sun, IBM-RT, or 
MicroVax), the next time on an IBM PC, or on any other machine on which the 
system runs, and will always see a consistent database of messages and user 
profiling information.   See the NonUnix documents for more information.


\p{Integration of communication database}:  The AMS treats mail, distribution 
lists, bulletin boards, and event calendars uniformly as \italic{messages}, 
allowing users to manipulate all of these after learning to use a single 
interface. 


\p{Separation of interface from functionality}:  The AMS architecture makes it 
easy to support multiple user interfaces while preserving for each the highest 
functionality.  For example, AMS supports a fancy bitmap-based interface for 
the advanced workstations (Messages), and a teletype-based interface which 
runs identically on the workstations, on dialup lines, and on IBM PC's (CUI), 
and a PC-based interface that uses menus familiar to PC users (VUI).


\p{Support for multi-media communication}:  The AMS is designed to support 
messages that include formatted text, complex graphics, and even animation, 
although some of these messages will obviously look their best only when 
viewed with the more advanced interfaces. 


\p{Support for coping with information flood}:  Several mechanisms in the AMS 
are being implemented as possible mechanisms for dealing with the flood of 
information that is increasingly overwhelming users of electronic 
communication systems on networks such as the ARPA Internet.  In order to 
permit the reasonable evaluation of these mechanisms, The AMS has been 
designed to prevent performance degradation in the face of the megabytes of 
messages now being fed into the system from diverse sites on various networks. 



\p{Flexible Architecture}:  The AMS has been designed for easy expansion to 
include various kinds of functionality not yet foreseen or implemented. 


}This paper will describe the AMS in major sections: 


\itemize{\p{Background}:  To understand the design of the Andrew Message 
System, it is first necessary to understand a bit about the structure of the 
Andrew project as a whole and its distributed file system (AFS) in particular. 
 We will also review some other related work in the area of electronic 
communication. 


\p{Desiderata}:  One of the first steps in the design of the AMS was an 
extensive survey of users of various electronic communication systems, in an 
attempt to define the largest possible set of goals for such a system.  We 
present the "wish list" gleaned from this survey, as it significantly shaped 
the design of the system.  Of course, it was never planned that we would 
implement every item on the wish list, but we did design our system to 
accommodate as many of them as possible, and the list should be useful to 
designers of future systems. 


\p{Architecture}:  In this section we describe the overall design of the AMS, 
and explain how certain aspects of the architecture are essential to permit 
the achievement of goals from the wish list. 

}
\section{1.2	Background}


\subsection{1.2.1	The Andrew System}


The Andrew project is a joint venture of IBM and Carnegie-Mellon University, 
started in 1982.  The goal of which is to produce a suitable working 
environment for academic use of computers.  The project is described in detail 
in [CACM-ARTICLE], but a few key points should be noted here. 


In Andrew, each user works on an advanced workstation (currently an IBM RT, 
Sun, or Dec MicroVax computer) running UNIX and connected to a campus-wide 
network over which it can talk to any of several dedicated file server 
machines.  There were two basic parts to Andrew, then known as VIRTUE and 
VICE.  VIRTUE was the user interface portion, which ran on the workstation, 
and includes a window manager, base editor subroutine library, and a number of 
application programs (e.g. the text editor) which exploited the facilities 
offered by the large bitmap display.  VIRTUE evolved to eventually become ATK. 
 VICE was the original name for the Andrew File System (AFS); it emulates a 
UNIX file system transparently, so that as users move from one workstation to 
another, the picture they see of their files remains consistent at all times. 


Both ATK and AFS have strongly influenced the design of the Andrew Message 
System  Each has made some parts of the system much easier and some parts much 
more difficult.  ATK, through the base editor library, makes it almost trivial 
to deal with multi-media messages, but thus introduces serious complexities 
into the manner in which messages are sent and received to non-Andrew systems. 
 AFS makes it easy to create a message database which is entirely 
location-independent, but introduces, by its very existence, new kinds of 
failure conditions neither expected nor dealt with robustly by software 
written for standalone UNIX systems.  In particular, the file system 
conceptually simplified the mail delivery mechanism, but at the same time 
mandated a complete rewrite of existing UNIX mail delivery programs. 


The stated objective of the Andrew project was to produce an effective working 
environment for high-function workstations.  Since one of the goals of the 
Andrew Message System was to produce a message system that was portable even 
to such lower-functionality machines as IBM PC's and Apple Macintoshes, this 
required that our design be more general than Andrew's, and in particular that 
our communication mechanisms, though based at bottom on AFS, be more general 
and more portable than AFS itself. 


\subsection{1.2.2	Relevant Previous work on Message Systems}


Although time and space do not permit us a complete survey of previous work on 
message systems, a few previous efforts influenced our design so strongly that 
they should be mentioned here.  The Grapevine system [CITATION] first 
demonstrated the feasability and utility of truly distributed electronic 
message systems.  Malone's work on the information lens [CITATIONS] has 
stimulated our interest in mechanisms for dealing with information flood, and 
indeed we hope to implement some of Malone's ideas in future versions of the 
AMS.  Part of the guiding vision for any modern view of electronic 
communication can be found in Turoff and Hiltz's works [CITATIONS], especially 
\italic{The Network Nation} [CITATION].  Our ideas about user interfaces have 
been shaped by a succession of user interfaces for mail and bulletin board 
systems, most notably TOPS-10 RdMail [CITATION], various Emacs-based message 
systems [BAGS & OTHER CITATIONS], earlier Andrew systems for mail and bulletin 
boards [CITATION], and several interfaces to the UNIX netnews system 
[CITATION].  Our passion for an integrated communication environment with a 
coherent and clean design can be traced in large part to personal experience 
with communication systems lacking in these aspects [CITE--BB PAPER]. 


\section{1.3	Desiderata for Electronic Communication Systems}


As stated previously, a central part of the initial design phase of the AMS 
project was the compilation of a "wish list" for electronic communication. 
 This list was derived from a series of surveys conducted via the ARPA 
Internet and several local electronic bulletin board systems.  Participants 
were encouraged to indulge their wildest flights of fancy; the primary purpose 
of the exercise was to insure that our initial vision was wide enough.  We 
tried to design the AMS to permit the eventual inclusion of as much of the 
wish list as possible, even if many of the features were beyond our initial 
resources for implementation.  To help provide the implementers of future 
systems with a vision at least as broad, we reproduce that list below: 


\subsection{1.3.1	The Wish List}


\paragraph{1.3.1.1	Delivery and Performance Issues}


\leftindent{100% reliable delivery -- All messages delivered, returned, or 
sent to maintainer. 


Fast delivery -- alternate delivery speeds, with fastest delivery at extra 
cost or for privileged users. 


Fast confirmation of delivery for senders' peace of mind. 


Simple delivery -- local users addressed by name only, with lookup in a 
community "phone book". 


Locally reliable support for external networks, including ARPAnet, uucp, 
BITNET, CSNet, etc. and all reasonable protocols (DARPA, uucp, CCITT X.400, 
NBS-10, SMTP, XMODEM, KERMIT)


Database of "clues" for paths to machines on external networks. 


Good construction of "Reply-to" addresses for responses to 
externally-generated messages. 


Conversion of all outgoing messages to conform to ARPAnet header standards. 


Robust delivery.  Automatic daily testing of connections to any cooperating 
machines (machines with a "BOUNCE" mail address, which simply sends all mail 
sent to it back to the sender unless it bears traces of a bounce loop). 


Hooks for users to specify automatic processing of incoming or outgoing mail. 
 The biggest use will probably be auto-cc's, which will be useful for 
forwarding external bboard notices and for allowing users to participate in 
experiments monitoring message system usage.  Will also be useful for 
"undigesting" messages arriving from external world in "digest" form. 


Automatic system monitoring.  Collection of aggregate data on system use and 
performance for fine-tuning the system and for research on message system 
usage.  Self-monitoring for internal consistency and automatic bug reporting. 


Fast performance of all "basic" functions -- sending mail, reading personal 
mail and standard message groups. 

}
\paragraph{1.3.1.2	Privacy/Protection Issues}


\leftindent{Dominant principle should be First Amendment:  all users should 
have as much self-expression as is feasible.  Also, privacy should be 
preserved to all reasonable limits. 

Each message classification will have separate categories identifying those 
users who can:  read the messages, enter new messages, edit the messages, 
respond to existing messages.  (Also, who pays for each message.) 


Access to external networks must be easily limited to certain individuals or 
specifically denied to certain individuals.  Access to the message system 
itself or to particular portions of it should be easily limited in the case of 
abuses. 


Provision for breaking privacy restrictions (e.g. to deal with antisocial 
behavior such as pseudonymously publishing credit card numbers) must be 
structured and limited.  For example, privacy restrictions may be circumvented 
only by three system maintainers acting as a group, supplying all three 
passwords. 


By default, the system should trust the login identification of a user, but it 
should be possible to make specific message databases (e.g. sensitive bboards 
or personal mail) accessable only with the use of a secondary password. 


Only data that does not identify individuals will be collected automatically 
and without user permission. 


"Pseudonymous" messages should be supported and protected.  Users should be 
able to send messages by pseudonyms, with their real identities known to the 
system but obtainable only in extreme circumstances (e.g. by a group of system 
maintainers together, as mentioned above).  Truly anonymous messages should 
not be possible, as experience with existing message systems indicates that 
this will lead to widespread abuses.  Provision should be made to allow people 
to communicate by pseudonym;  that is, the pseudonyms will serve as aliases 
understood by the mail system but not revealed by it.  Provision should also 
be made for mutual revelation of pseudonyms; "I'll tell you mine if you tell 
me yours" should be an enforceable offer, with the revelation of identities 
mutual and simultaneous. 


The creation of new user or group identities should be controlled but 
flexible.  Anyone should be able to create anonymous or pseudonymous users, 
but these should be clearly discernable as such.  (That is, pseudonyms should 
not resemble real names such as "Ronald Reagan", but instead should be 
something like "pseudo-Ronald Reagan".)  Users should be able to create users 
that appear as "versions" of themselves, e.g. "John Doe.secretary". 


When messages are modified, a modification history should preserve so that 
claims about its previous state may be investigated and settled. 

}
\paragraph{1.3.1.3	Economic Issues}


\leftindent{Ability to charge users either for each message sent or for 
storage of preserved messages, or both. 


Ability to charge users for the privilege of reading your message or database. 



Alternate delivery speeds, with fastest delivery at extra cost. 


Ability to charge varying amounts for varying types of message and delivery. 


Ability to surcharge senders of "junk mail"; when abusive or excessive mail is 
sent, the recipient should be able to (moderately) increase the cost to the 
sender. 

}
\paragraph{1.3.1.4	Message Structure and Database Issues}


\leftindent{First class mail:  mail from one individual to one or more other 
individuals. 


Registered Mail, Return Receipt Requested:  For a still higher charge, the 
confirmation will occur only after a human recipient has agreed to confirm 
receipt of the mail.  Recipients can refuse receipt of such mail, but will 
then be unable to read the mail's contents. 


Parcel Post:  Mail may enclose or consist of files as "parcels".  Software on 
the recipient end should make it simple to restore a file to its original 
format in the recipient's disk area.  Special provision should be made for 
encoding and decoding binary files and groups of files, and for "peeking" at a 
file before allowing it to appear on your disk space. 


Form Letters:  Provision should be made for constructing form letters to be 
sent out in customized form as appropriate (for example, explaining rules for 
using a laboratory, etc.). 


Mailing lists:  mail to a public or private list of people.  In a private 
list, the complete set of recipients may not be visible to those recipients 
without the proper access privileges. 


Spreading distribution list or "approval sequence".  Messages can be sent to a 
group of people specifying additional recipients to whom the message will go 
after the first recipients verify the message. 


Messages to more than one individual implemented efficiently (i.e. with 
minimal multiple physical copies). 


Message databases:  in addition to individuals, messages can be sent to 
databases (bulletin boards) which may be public or private to groups.  Each 
message database has its own protection status, a policy statement explaining 
the purpose and conventions of the database, and a "duration" specification 
telling how long messages exist once they appear.  Each database also has a 
set of responsible parties who can edit and delete messages, and a party who 
is charged for the storage used by the database.  Databases should be logical 
entities; a message in multiple databases need not exist in two physical 
copies.  Individual mail will appear simply as a private message database. 
 Users should be able to define logical message databases which combine 
message databases, and to use such logical database names in commands relating 
to reading and writing messages.  (When a user tries to send a message to such 
a logical database, the system should give him the option of sending to all or 
some of the components, e.g. sending messages to sf-lovers locally and/or on 
usenet and/or on ARPAnet.)  In addition to databases which are added to by 
specific actions, other databases may be constructed to which messages are 
automatically added when they match certain criteria.  (However, these 
databases must not interfere with the other protection mechanisms;  a message 
on a private database should not become public simply because it contains a 
certain key word.)  It should also be possible to search message databases by 
arbitrary key words and for other specific message information.  Incorrectly 
classified messages -- those inappropriate to a specific database -- should be 
easily reclassifiable by individuals with the appropriate access rights.  Each 
database can be divided into sub-databases to deal with particular sub-topics, 
and individuals should be able to specify that they are reading only the 
top-level notices, all notices recursively, or some combination of some but 
not all sub-databases. 


Reviews of Messages:  Any individual with read-access to a message database 
should be able to declare himself a "reviewer" for that database.  He will 
then indicate whether or not each message he reads is worth reading.  Other 
individuals can then use his reviews, or an arbitrary function of the reviews 
of several reviewers (e.g. a majority vote, weighted average, etc.) to 
pre-screen messages.  Provision should be made for helping users choose 
reviewers, for automatically using all active reviewers, and for not 
penalizing users who depend on the views of a reviewer who becomes inactive. 
 (Using all active reviewers is actually a form of voluntary voting about 
messages, which may be most desirable for certain types of databases.  It 
might even be the criterion for the duration over which an individual message 
is preserved.  For this type of database, it might be desirable to consider 
every user a reviewer, but to maintain only aggregate reviewing data.) 


"Hooks" should be left in the system to allow for future incorporation of 
"intelligent" automatic classification mechanisms and filters on incoming and 
outgoing mail. 


The system must be designed to support an aggregate database of messages that 
is enormous, probably including millions of messages, some very long. 


The message format should use the internal ITC datastream, to allow for 
inclusion of mixed text, graphics, and any other media which will be locally 
supported.  Such local dependencies must be filtered out at the interface with 
external networks, and when transmitting message bodies to PC's and other 
machines that do not support the full datastream. 


Messages should be easily encoded and decoded using public key cryptography. 
 A less costly encoding scheme should be available for potentially offensive 
notices, along the lines of the netnews "rot13" convention. 


Everyone who reads a message should have the option of responding to it; 
messages posted in response to other messages (annotations, corrections, 
rebuttals, answers, etc.)  should appear as a subgroup of messages visible 
when the user is looking at the base message.  A message may be posted in 
response to another message, as a new message in its own right, or both.  Thus 
the overall structure of the message database is a DAG.  (The structure is 
acyclic because no message can ever be a response to a later message.)  In 
general, if the system showed you a message it will show you the responses, as 
they come in, as a "sub-database" to which you are subscribed.  Provision 
should be made for smoothly converting a message which generated many 
responses into a genuine sub-database, which individual users can then 
explicitly specify a preference or aversion to seeing. 

}
\paragraph{1.3.1.5	Timing & Editing Issues}


\leftindent{Associated with each message should be several pieces of timing 
information:  when the message is to appear, how long it should last before 
going away (possibly forever), and how often to appear (possibly at regular 
intervals, e.g. every April 1 or on the third Tuesday of each month),.  Also 
stored with each message should be a note describing any need to archive a 
message before deletion. 


For each message group, certain users should have privileges allowing them to 
edit all messages, again with an appropriate audit trail. 


Any user should have the right to try to edit any message he can read;  if he 
is not permitted to actually edit it, he should be able to submit it as a 
suggested edit to someone who does have the right to edit it. 


Deleting a message will be subject to the same rules as editing a message. 


Messages will have associated with them a "time of last modification".  This 
time is updated each time a message is created or edited, and each time a 
response to the message (or a response to a response, etc.) is created.  Users 
will be able to search the database to find messages in certain categories 
modified after certain times, or to see all messages regardless of 
modification time.  Since people most often use such systems in "update" mode 
-- that is, seeing all messsages that have appeared since the last reading -- 
the database should be structured for maximum efficiency in this situation. 

}
\paragraph{1.3.1.6	Interface Issues}


\leftindent{The system must be portable; it must run on a wide range of 
hardware from state-of-the-art workstations to teletypes.  The set of messages 
seen, and the state information about what has been seen in the past, should 
be the same for a given user no matter what hardware he is using.  That is, it 
should be routine to read mail one day on one machine, and the next day on a 
different machine. 


The interface on the various machines should be as consistent as possible.  A 
"dumb" typescript interface should be available on all machines to maximize 
consistency.  A "smart video terminal" interface should be available 
consistently on all hardware that can support it.  Advanced interfaces on 
workstations should be kept as consistent with the other interfaces as 
possible, with the other interfaces available as a subset of the advanced 
system.  As much code as possible should be written in highly portable C, to 
help maximize consistency. 


The aforementioned standard interfaces should have distinct styles, to suit 
the inevitable disparities of user preferences.  The typescript interface 
should be command-driven, the full-screen interface should be 
control-character-driven (a la Emacs), and the workstation interface should be 
mouse-and-menu-driven.  A prompt-driven novice interface would also be 
desirable, as would a stream-oriented interface for use by client programs. 


The command-driven programs should be designed to easily support multi-lingual 
interaction, to simplify use of the program for foreign nationals or in ports 
to foreign sites. 


The full screen interfaces should use windowing to divide the screen, when 
appropriate, into areas for message headers, message bodies, message 
composition, help, and typescript-style interaction.  Not all such windows 
need always be visible, however.  All windows should be independently 
scrollable. 


Commands should give simple support to file operations, such as writing 
messages into files, reading files into messages being composed, and so on. 


Messages should be easily printed or added to additional public or private 
databases.  Appropriate conversions should be easily made for converting a 
"current" notice into a "reminder" notice about an event on a future date. 


Features should easily permit replying to messages and forwarding messages. 


It should be easy to get a list of all message groups, or all message groups 
matching certain criteria. 


For those with the appropriate privileges, it should be a simple matter to 
alter the protection status of a message group, e.g. to give new people 
permission to read or write messages in it. 


Generally irrelevant state information -- e.g. most headers from messages 
arriving via the ARPAnet -- should be generally invisible, but available on 
request. 


As many interface features as reasonably possible should be made customization 
options, to give users more control over the style of interaction. 
 Customization information, like messages themselves, should be universally 
available regardless of hardware being used, even though some of it may be 
ignored by some interfaces. 


The interface should validate all addresses for outgoing messages as early as 
possible, so that the user need not wait until the final delivery attempt to 
learn of addressing errors. 


Provision should be made for automatically informing those users who want to 
be informed about the creation of all new message databases to which the user 
has access privileges. 


Error messages should be clear and informative. 


Useful on-line help and a readable, "need-to-know" structured manual should be 
available. 


Spelling correction should be available for all messages being composed.  It 
should be automatic or optional, at the user's preference. 


All commands should be specifiable either as command line arguments, as 
entries in an initialization file, or interactively as the program is run. 

}
\paragraph{1.3.1.7	Integration Issues}


\leftindent{The system should integrate all locally available media, e.g. 
graphics. 


The system should have a smooth interface with external networks. 


The system should be well-integrated with local application programs. 


The system should be able to be integrated with future electronic funds 
transfer mechanisms, to allow users to mail each other money, for example, or 
to pay bills from their workstations. 


The system should be available on nearly all the machines on the CMU campus, 
specifically including Andrew workstations, IBM PC's, Macintoshes, VAX systems 
running both UNIX and VMS, and TOPS systems.  Those machines not integrated 
into the new system should at least be able to communicate via mail at the 
same level as machines on external networks. 


Wherever possible, automatic mechanisms should be provided to allow users to 
move messages from an older mail system to the new system, thus lessening 
transition costs. 


The system should be as extensible as possible; everything should be written 
in as general a way as efficiency allows, so that unforseen future additions 
to the system are more likely to be possible. 

}
\section{1.4	Architecture}


\subsection{1.4.1	Two process architecure}


One particular item from the wish list -- the desire to have the system 
available on the widest possible range of machines -- has played a major role 
in the architecture of our system.  In order to make the system available on 
such low-end machines as the IBM PC and Apple MacIntosh, it was clearly 
necessary to segment the functionality of the system into two major parts: 
 the part which accesses, stores,  and alters information in the database, and 
the part which interacts with the user on whatever machine he or she is on. 
 The former, which we call the \italic{message server}, must run on a machine 
with full access to the message database stored in AFS.  The latter, the user 
interface component, needs only to be able to talk to a message server via an 
agreed-upon mechanism. 


The mechanism by which the message server and its clients communicate is 
called SNAP (for Simple Network Application Protocol), which was developed for 
both the Message System and to connect IBM PC's to the Vice file system via 
special servers.  SNAP is a very simple communication package that may be used 
by applications to perform remote procedure calls.  Communication in SNAP is 
decidedly one-way; the client makes calls upon the server and waits for 
answers from it.  The client code in SNAP has been kept extremely simple to 
facilitate portability to multiple machines.  Communication via SNAP is also 
connectionless; packets are sent back and forth as datagrams, with essentially 
no connection state. 


The simple picture of a client talking to a message server via SNAP is not, 
however, the whole story.  AFS has an elaborate authentication mechanism by 
which it guarantees the security and privacy of users' files.  Since the 
connectionless nature of the SNAP conversation would make it extremely easy 
for \italic{any} process on the network to talk to a message server, some 
mechanism needed to be provided to guarantee the security of these 
conversations. 


The main guarantor of security and authentication in the message system is a 
process called the \italic{guardian}.  The guardian acts as the "gateway" to 
all SNAP servers.  When a client wishes to open a conversation with a message 
server, it first contacts the guardian on the appropriate machine and says, in 
effect, "Give me a message server."  It provides a user id and a password. 
 The guardian then authenticates the user with AFS (an elaborate procedure 
which involves talking to the AFS authentication server).  If the 
authentication succeeds, the client is given the address of a message server 
and an encryption key.  (If no message server is yet running for the user on 
that machine, the guardian starts one, which it can do because it runs as 
root, the UNIX superuser.)  The security of the conversation between the 
client and the message server is thus doubly guaranteed:  without 
authentication, in order to break into the system a user must first *guess* 
the address of a running message server, and then guess the  encryption key. 
 The guardian also performs a few other useful services, such as giving 
clients early notification if the message server has gone away. 


So far we have seen only the process-level architecture of the system.  Next 
we will consider, in turn, the two major parts of the system, the message 
server and its clients. 


\subsection{1.4.2	Message server, White Pages and Delivery system}


The message server, as stated previously, performs all of the actual 
database-related activities in the message system.  It also acts on requests 
from clients to look up user names and to deliver messages to other users.  To 
do this, it interacts with two other, as yet unmentioned, components of the 
Andrew Message System, the \italic{White Pages} and the \italic{delivery 
system}. 


The White Pages are a subroutine library which matches incomplete user name 
specifications to known user names.  In particular, it does "best-matching" on 
partial names, so that a user can address mail to "N Bore" and have this 
automatically matched to the user id "nsb", which belongs to "Nathaniel 
Borenstein".    See the WP documents for more information on the White Pages.


The delivery system is another extremely complicated subsystem.  This is a 
suite of programs dedicated to the process of actually moving mail from one 
user to another.  These programs are complex primarily because of the effort 
devoted to making mail delivery reliable in the face of network problems, AFS 
problems, and other complications.   See the AMDS documents for more 
information on the Delivery System.


\subsection{1.4.3	The Message Server Clients}


In previous sections, the overall architecture of the message system was 
described in terms of the guardian, the message server, and the message 
server's clients.  In this section, we will at last discuss the clients, which 
are the programs that users actually see. 


Each of the clients is linked with a subroutine library, called the 
\italic{common user interface library}, or CUI library.  The CUI library 
includes SNAP and all of the procedures that hide SNAP from the interface 
programmer (by providing the apperance of direct calls to the message server), 
and some additional abstractions of context which are not provided by the 
connectionless nature of the interface with the message server. 


The simplest client is simply called the cui, or common user interface.  This 
program, like the cui library, is written in extremely portable C and make 
only minimal assumptions about the runtime environment and machine type.  This 
makes it possible to promise that cui will be available on every system that 
supports the Andrew Message System, allowing users who switch frequently 
between systems to avoid learning more than a single interface.  Accordingly, 
the cui is line-oriented, and can run equally well (or equally poorly, 
depending on how you feel about such simple interfaces) on an advanced 
workstation, a PC, and a teletype communicating over a dialup line. 


The most advanced client of the message server it the program known simply as 
\italic{messages}.  This is a program which runs only on a workstation (Sun, 
Vax, or IBM RT) running the Andrew window manager.  The messages program 
includes the ATK \italic{base editor subroutine library}, which provides 
application programs with multiple fonts, multiple display areas, scrollable 
displays, and intermixed text and graphics. 


\section{1.5	Acknowledgements}


A large number of people have participated in the design and implementation of 
the Andrew Message System, and an extremely large number of people -- our user 
community -- have helped out with comments and suggestions.   In addition to 
the authors, important work has been contributed directly by Mark Chance, Sue 
Pawlowski, Bob Glickstein and Adam Stoller.  Moreover, the system would not be 
possible without extensive libraries and other facilities provided by the rest 
of the Information Technology Center at Carnegie Mellon, most notably the AFS 
Group and the User Interface Group.  Their contribution is gratefully 
acknowledged.



\begindata{bp,537558784}
\enddata{bp,537558784}
\view{bpv,537558784,1468,0,0}
Copyright 1992 Carnegie Mellon University and IBM.  All rights reserved.

\smaller{\smaller{$Disclaimer: 
Permission to use, copy, modify, and distribute this software and its 
documentation for any purpose is hereby granted without fee, 
provided that the above copyright notice appear in all copies and that 
both that copyright notice, this permission notice, and the following 
disclaimer appear in supporting documentation, and that the names of 
IBM, Carnegie Mellon University, and other copyright holders, not be 
used in advertising or publicity pertaining to distribution of the software 
without specific, written prior permission.

IBM, CARNEGIE MELLON UNIVERSITY, AND THE OTHER COPYRIGHT HOLDERS 
DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING 
ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS.  IN NO EVENT 
SHALL IBM, CARNEGIE MELLON UNIVERSITY, OR ANY OTHER COPYRIGHT HOLDER 
BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY 
DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, 
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS 
ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE 
OF THIS SOFTWARE.
 $

}}\enddata{text,539484024}
