\section{User Interface} % # 3.5

The original interface we designed for discuss was selected for its
simplicity and (for some of us) familiarity.  It is a tty-oriented
interface, looping through a prompt-input-execute sequence.

The user is presented with the idea of a meeting currently being
attended, and a "current" transaction within that meeting; she may go
to a different meeting, or run one of many commands within a meeting.
The commands available for examining the contents of a meeting include
"list" and "print"; each takes one or more transaction numbers (plus
names for special transactions such as the first or last transactions
in the meeting and other transactions in the same chain as the
"current" transaction).

Naturally, input modes are necessary as well; we provide "talk" for
entering transactions to start new chains (or to stand by themselves),
and "reply" to enter a response to an existing transaction.
The "talk" command requests a subject, then allows the user to enter
the text of her message.  It uses a simple mail-like line-input
interface, terminating the message on a line containing only a '.' or
escaping to run $EDITOR on "~e".  Although the protocol does permit
new subjects for any transaction, the "reply" command currently
assumes a subject derived from the message being replied to, prefixed
with "Re:" if it is not already present.  A "delete" command is also
provided.  \marginpar{notes include mention of
delete/retrieve/expunge; expand on this}

There are also commands for dealing with several meetings; aside from
the "goto" command mentioned above, we have provided a command
"check_meetings" which checks whether any meetings the user attends
have changed since the user last attended them.  The command
"next_meeting" can be used to step through this list meeting by
meeting, allowing the user to view all the new transactions in any
meeting he attends.

\section{Notifications} % # 7

We quickly found it desirable to be able to find out when certain
meetings of interest had new transactions entered.  Since possible
uses of a meeting may include a running conversation, it is sometimes
desirable to be notified in real time of the entry of a new
transaction.

Another project under development at MIT, Project Athena's Zephyr
Notification Service \marginpar{ref zephyr paper}, provided just the
capability we needed.  It provides a mechanism for issuing broadcast
or multicast messages to users on a large number of workstations.
(Issuing a "write"-type message to users on the local machine is also
a possibility, but would be of very limited utility in the workstation
environment.)

Naturally, since some meetings are of very restricted accessibility,
these meetings should not have notifications broadcast to every user
on the network.  The policy we have chosen to follow are that any
meeting with "read" access granted to "*" (any user, authenticated or
not, unless specifically excluded) has broadcast notifications; other
meetings use multicast notifications to those users who have read
access to the meeting.  (There are instances where a meeting is
accessible to everyone but one or two users; this has been cause for
some reconsideration of this notification policy.)

\section{Foo, bar \& baz} % # 8

In working on this project, we came across a number of problems that
needed some sort of solutions; in the cases where the solution took
the form of a class of library routines, we attempted to keep the
design of these libraries independent of discuss itself, and indeed
a couple of these have found uses elsewhere.

One of the first problems to tackle was the number of different
software packages involved which could return error status numbers,
all starting from zero and overlapping in ranges.  We dealt with this
by creating yet another package designed explicitly to provide a
unified interface for dealing with error messages.

The Common Error-handling (com\_err) package uses, as input, named
tables containing C preprocessor symbols and text messages, and
produces as output a C include file defining the preprocessor symbols
(up to 256 in each table) as integers, sequentially assigned, starting
with a number derived from the name of the error table.  A C source
file is also produced containing the text of the messages and an
initialization routine which adds the table to the list of those known
by the com\_err library.

Routines are naturally provided which can retrieve the text message
from the appropriate table, or produce a substitute message if the
text is not accessible.  (This substitute is generally cryptic, but
can be used in conjunction with the sources to determine just what the
error was, and which table the programmer forgot to access.)

Since the initialization routine accompanying each error table has a
name derived from the name of the table, collisions in error numbers
(and therefore in error table names) show up at link time rather than
at run time when the programmer tries to track down the meaning of
some small integer value.

Of course, not all the packages we use were written with this in mind.
Thus, when a routine from some other package (for example, the
Kerberos authentication system) is called and returns a non-zero
status, our code modifies the returned value (generally by adding a
constant).  We have reserved error table number zero for UNIX system
error codes (a la errno); this simplifies some problems.  (Some
packages we have been using, such as Zephyr, were designed to use this
method for handling error codes; thus no conversion is necessary to
interface with these routines.)

Another important package we had to write for this project was the
driver of the user interface itself.  While the routines implementing
the specific commands are very particular to discuss, the driver that
prompts for them is not.  The package we use provides the input and
dispatch routines for our discuss client program, a control program
used by Zephyr, one of the Kerberos administrative utilities, and
various other command-processing subsystems.

This subsystem driver consists of a command-table translator which
converts a descriptive list of commands (including several command
names, a short one-line description, and a subroutine name for each)
into a data table, and a library which utilizes this table.  The
routines which are invoked by the dispatcher are called with the
familiar "argc, argv" arguments, plus a couple of others of use to the
subsystem library for internal management.

This subsystem package includes as built-in commands a "?" command
which lists the commands available, with their descriptions, and some
simple commands like "quit".  It manages input handling, primitive
shell-like argument parsing (breaking up a string into an array of
words), and a help utility that makes use of programmer-supplied
directories of help files (to be viewed with "more").

More sophisticated versions of this package, which include more
intelligent argument parsing and command completion, are in the works.