\section{Client/Server Model}

One of the goals of {\it Discuss} is that it is distributed.  Unlike
its timesharing-based relatives, {\it Discuss} allows meetings to be
shared among users working on different machines.  The design of {\it
Discuss} addresses the problems of distributing its functions
across different machines.

The MIT computing environment, as described in Section \ref{distenv},
influenced the design of {\it Discuss}.  Almost all MIT computers are
connected to a set of high-speed networks and gateways, allowing fast
data transfer between any two machines on campus.  In addition, most
students use public Athena workstations, which are single-user UNIX
machines with graphic displays.  These workstations have spare CPU
time, but retain no local state.  MIT computers form a loose
federation of autonomous systems.  In particular, MIT has no common,
network-wide file system that could store all {\it Discuss} meetings.  
This differs from the Carnegie Mellon bboard system\cite{andrew} which uses
the Andrew File System to distribute meetings among many machines.

Given the MIT environment, {\it Discuss} uses the client/server model of
computation.  With this model, an application is divided into two
parts.  One part, the server, manages a resource, while another part,
the client, accesses this resource across the network by contacting
the server.  The client/server model is a common model for other
applications in the Athena environment; it encapsulates the particular
resource within the servers.

\subsection{The {\it Discuss} Server}
With {\it Discuss}, the particular resource is the set of 
meetings on a given machine.  A server provides
access to these meetings, allowing clients to manipulate them
in a controlled fashion.  The pool of {\it Discuss} meetings is
distributed among various servers; unlike a {\it netnews} group, a
{\it Discuss} meeting is located on a single machine.  This allows all
participants to have a consistent view of the meeting, 
but requires low-latency network connectivity.
The transactions are numbered consistently, and users can immediately
see new transactions entered by other participants.

A {\it Discuss} server provides a low-level interface for manipulating
meetings.  The operations are fairly primitive, allowing clients to
get information about single transactions and single meetings.  The
server simply manages the meeting data, ensuring its consistency and
controlling access to it.  The server provides a core set of
operations that can be used by any user interface.  A sample set of
these primitives is shown in Figure \ref{dops}.
\begin{figure*}[tp]
\hspace*{0.75in}{\tt get\_mtg\_info (mtg\_name) returns (mtg\_info, err\_code)} \\
\hspace*{0.75in}{\tt get\_trn\_info (mtg\_name, trn\_num) returns (trn\_info, err\_code)} \\
\hspace*{0.75in}{\tt get\_trn (mtg\_name, trn\_num) returns (trn\_text, err\_code)} \\
\hspace*{0.75in}{\tt add\_trn (mtg\_name, trn\_text, subject, reply\_trn\_num) } \\
\hspace*{1.35in}{\tt returns(new\_trn\_num, err\_code)}
\caption{Sample set of {\it Discuss} server operations\label{dops}}
\end{figure*}

On a UNIX {\it Discuss} server, a meeting is stored as a directory
owned by the {\tt discuss} user on the server machine.  The name of the
meeting is the name of this directory; {\tt /usr/spool/discuss/ping}
is a sample {\it Discuss} meeting name.  The meeting can be located anywhere
within the server machine's filesystem.  This allows users with
accounts on a server machine to create {\it Discuss} meetings under
their home directories.  A {\it Discuss} meeting contains three
files: {\tt transactions}, {\tt control}, and {\tt acl}.
The {\tt transactions} file contains the text of the transactions,
stored in an append-only format.  The {\tt control} file contains
indexes into the {\tt transactions} file, as well as information about
transaction chains and deleted transactions.  The {\tt
acl} file contains the access control list for the meeting.  Access
control is described later in this paper.

{\it Discuss} meetings should be placed on machines that have
sufficient amount of disk space to support the meetings.  Since {\it
Discuss} meetings are archival in nature, this disk space should be
backed up regularly\footnote{A lesson learned the hard way.}.  {\it
Discuss} server machines should also have enough computing power to
support the expected number of clients.

\subsection{The {\it Discuss} Client}
A user accesses {\it Discuss} meetings by running one of the various
{\it Discuss} client programs.  This program manages the user
interface and contacts the appropriate servers to manipulate the
meetings that the user attends.  The client program displays the
information contained in a meeting and allows the user to enter new
transactions.

Since the client/server interface is low-level, it does not dictate a
particular user interface; different clients can present different
user interfaces, provided that they fit into the meeting model
explained above.  Currently, there are five different {\it Discuss}
clients: {\tt discuss}, {\tt xdsc}, a {\tt Common Ground}
implementation\cite{cg}, {\tt dsmail} and an emacs\cite{emacs}-based
client.  {\tt discuss} is the general command interface described
above.  {\tt xdsc} is an experimental client based on the X window
system\cite{x}.  {\tt dsmail} is a utility program that automatically
enters mail messages into {\it Discuss} meetings, trimming the headers
appropriately.

In the client/server interface, a {\it Discuss} meeting is named by
its server machine name and its location on the server machine.  Since
these names are difficult for humans to use, the client program
accepts simple mnemonic names for meetings, and converts them
into
this low-level form.  This mapping could be provided by a name service
such as {\it Hesiod}, but none existed at the time {\it Discuss} was
initially designed.  Instead, a user file called {\tt .meetings}, in
the user's home directory, is used.  This ASCII text file records what
meetings the user attends, storing its low-level name and the simple
names that can be used to refer to the meeting.  This allows users to
have personal aliases for the meetings they attend.  The {\tt
.meetings} file also contains information about what transactions the
user has seen in a given meeting.  This information is kept on the
client side because of a desire to keep the server simple, and also
because of concerns that such information shall be private.