%
% Stan's latex macro package, stolen from Simson
%
% I'm calling them ``hugecap'', 'cause that's what they are.

%
% Standard settings....
\newcommand{\standardsettings}{
	\setlength{\oddsidemargin}{0in}
	\setlength{\evensidemargin}{0in}
	\setlength{\topmargin}{-2pc}
	\setlength{\headheight}{3pc}
	\setlength{\headsep}{2pc}
	\setlength{\textwidth}{6.5in}
	\setlength{\textheight}{8.5in}
	\setcounter{secnumdepth}{-3}
	\setcounter{tocdepth}{3}
}
\newcommand{\stdsizes}{\standardsettings}
\newcommand{\feature}[1]{\subsection{#1}}

\documentstyle[11pt]{article}
\stdsizes
\begin{document}
\title{Discuss Enhancements Requirements}
\author{Stanley Zanarotti}
\date{22 July 1992}
\maketitle
\section{Introduction}
This document identifies a set of requirements for enhancing the
Discuss networked electronic conferencing system.  As directed by the
Opportunity Evaluation, this document describes a number of desirable
features and improvements to Discuss.  It provides a list of desired
features, an analysis of their costs and implications, and
recommendations of what to implement.

This list was gathered from two sources: the archive of previous
Discuss suggestions and bug reports (the {\tt discuss} discuss
meeting), and interviews with a number of leading Discuss users in
DCNS, CSS, and ACS.  These users were chosen because of their heavy
use of Discuss, and their suggestions in the past.  The interviews
were used to learn which Discuss interface they used, and provided
emphasis to those features that would help their job the most.

The interviews and resulting features are biased towards Information
Systems' internal use of Discuss.  Most of these users have used
Discuss for years, and are quite familiar with its user interface.
Although the faculty liaisons and Help Desk considered their
respective customers, most of the feedback centered around frequent
users.  If we had wanted to identify requirements to substantially improve
the user interfaces or reduce the learning curve, we would have
conducted interviews with more casual users.

The archive and interviews produced a total of 63 suggestions and bug
fixes to Discuss, of varying importance and levels of difficulty.
Implementing all of them would involve a substantial effort and
consume more resources than is practical.  We therefore must choose a
set of requirements based on importance and expected effort.  In this
document we divide the suggestions into 3 categories:

\begin{enumerate}
\item those that should be implemented in this round of improvements,
\item those that may be implemented if there are sufficient resources, 
\item those that will be left to other projects.
\end{enumerate}

In order to choose between these categories, we need to have a rough
idea of the available development resources.  We assume two to six
months of Stan Zanarotti's elapsed time, with 4 to 5 days of
billable time per month. 

\section{Compatibility requirements}

Discuss is a running system with an installed base of meetings,
Discuss servers and client programs.  We must assume that any upgrades
will be installed at varying times on the MIT network, and may even be
backed out if problems occur.  Different versions of Discuss software
will need to interoperate smoothly, otherwise the amount of effort to
install a new version would greatly increase.  Therefore we have the
following set of compatibility requirements:

\begin{enumerate}
\item An old Discuss client should be able to work with a new Discuss server without problems.
\item A new Discuss client should be able to work with an old Discuss
server without problems.
\item A new Discuss server should be able to use an old meeting automatically.
\item There must be some mechanism to revert a Discuss meeting modified
by a new server so it can be used by an old Discuss server.
\item If an old server and a new server cannot interoperate on a meeting
format, it should be clearly documented how the servers interact.
\end{enumerate}

\newpage
\section{Features to be implemented}

\feature{Named flags on transactions}
Currently the Discuss user interface provides access to only one flag
per transaction, although the server is capable of storing 15 flags.
For meetings that track tasks, these additional flags could be used to
record additional status information. The user interface should allow
users to set multiple flags on a transaction.  Since it would be
difficult for users to keep track of flag numbers, these flags should
somehow be named to reflect their semantic meanings.  These meanings
will vary from meeting to meeting, so the meeting will need to keep
track of the flag names.

To implement this feature, the Discuss server will need to be changed
to store the mapping between flags and their names.  The protocol
will need new operations to set and retrieve flag names.

The user interface will need to be altered to display these additional
flags on transactions, and new commands will be needed to set flag
names and flag bits.  New transaction specifiers would be needed to
select transactions by what flags have been set or not set. (4-5 days)

\feature{Searching of meetings on server}

Currently the only way of searching a meeting for some given text is
either by printing out all transactions and using the search
capabilities built into {\tt more}, or by using {\tt dsgrep}, a separate
utility program developed by Lucien Van Elsen to search the OLC logs.
Both methods are rather slow, because the text of all searched transactions is
sent from the server to the client to be searched.

A more efficient way of searching would be to perform the search on
the server, and send the transaction numbers of matching transactions
back to the client.  Although full regular expressions, such as those used
in {\tt grep} or {\tt emacs}, would be the most general way of specifying
searches, a simpler but useful method would be a series of keywords,
with either AND or OR conjuctions between them, that would be searched
in a case insensitive manner.

To implement this feature, the Discuss protocol would need a new
search request to send the keywords to the server, and receive the
transaction numbers back.  The server would need to implement this
feature, being careful about not locking the meeting too long for new
transactions.  The tty user interface would need to be changed to make
use of this feature, with some syntax in the transaction specifiers to
select a set of transactions based on keywords. (4-5 days)

\feature{Rechaining transactions}

If a Discuss transaction is accidentally chained to the wrong
transaction, or starts a new chain when it should actually be chained
to a previous transaction, there is no way to fix up the situation.

The Discuss server should allow transactions to be rechained after
they are entered.  A new request, rechain, should be added to the
protocol to implement this feature. (1 day)

\feature{Use Moira to generate Discuss acls}
Discuss Access Control Lists (ACLs) only allow a list of individuals
to be given access, and have no way of setting access for Moira
groups.  For meetings where an organizational group of individuals need
access, such as the OLC logs, the meeting acls need to be updated
whenever the group changes, tracking changes that are already made in
the Moira database.  If Discuss and Moira were tied closer together,
it would reduce the administrative work for maintaining Discuss acls.

There are two ways of implementing this feature.  One way would be to
have Moira generate all Discuss acls.  Since Discuss acls specify not
only individuals, but the access these individuals have, Moira would
then need to have some way to encode the ``acdorsw'' capabilities,
most likely by having 7 lists for a single Discuss acl.  With 497
meetings, this would be add load to the Moira database.  This approach
would also go against the distributed philosophy behind Discuss, since
creating Moira lists is tightly controlled in the Athena environment.

The second approach is to use Moira to generate group lists, and have
Discuss acls refer to these group lists to give access to groups.  The
acl syntax would be changed to have a way to support a group name,
such as ``:consultants''.  The group membership would be stored in a
file or set of files on the Discuss server machine, and the Discuss
server would refer to these files to check if a principal is in a group.

We choose the second approach because it does not add significant load
to the Moira database, and it gives meeting chairmen more autonomy to
control access to their meeting.

If an individual is specified in a Discuss acl, the access specified
for the individual overrides the access due to group membership.

If an individual is not specifically listed in a Discuss acl, but
belongs to several groups in a Discuss acl, the access will be that of
the first group listed.

Some thought will need to be put into deciding what groups Moira
should be generated for a Discuss server.  A simple approach would be
to generate all Moira groups, but this would be slower to generate,
slower to access, and take more disk space.  Since only a few groups
would be used in Discuss meeting acls, it might be useful to have
Moira identify these groups, and only generate these groups for a
Discuss server.  This depends on how difficult it is to add an
attribute to Moira groups. (1 day)

\feature{Hesiod to add meetings}

To add a new Discuss meeting, a user either needs to know the 
pathname for the meeting and what Discuss server the meeting is on, or
find a meeting announcement in one of the announcement meetings.  Both
approaches are difficult for new users to deal with, especially when a
friend told them to ``add the ijr meeting.''  Using Hesiod to maintain
a single-level namespace would simplify this process, removing a
significant barrier for new users.

There are three possible ways of using Hesiod in Discuss.  The
simplest and easiest to implement would be to use Hesiod when adding
meetings.  The user could specify a simple name, which would be looked
up in Hesiod to find the server and pathname, which are then added to
the user's {\tt .meetings} file.

The second approach would be to store simple names in the {\tt
.meetings} file, and use Hesiod to figure out the server names and
pathnames dynamically.  This allows meetings to migrate between
servers without notice, but slows down the process of checking
meetings, requiring a Hesiod request for each listed meeting.  This
approach may also force all meetings to be listed in Hesiod, even
private meetings.  This approach requires more work, since the {\tt
.meetings} format will have to be changed or updated.

The third approach would be to use Hesiod when adding meetings, like the
first approach, but also to use Hesiod when an error occurs locating a
Discuss meeting.  If a Discuss server is down, or the meeting
disappears on a server, the client would use Hesiod to see if the
meeting is moved, and update the location automatically.  This has the
advantage of allowing arbitrary meeting moves for meetings listed in
Hesiod, without the overhead of repeated Hesiod requests.  The server
and pathname in the {\tt .meetings} file is a ``hint'' of the meeting
location.

We choose the first approach, since it requires the least amount of
effort to implement, while significantly improving the method of
adding meetings.  If resources are available, we can work on
implementing parts of the third approach. (2 days)

\feature{Faster listings}

When listing transactions, retrieving the information about each
transaction involves a network round-trip between the server and the
client.  This slows down listings.

Adding a list range request to the Discuss protocol will batch
requests for transaction information, and speed transaction listings.
The request should be added carefully so that it does not excessively
lock the meeting, or cause listings to be jerky.  User interface
research shows that users prefer consistent response time over
variable response times. (1/2 day)

\feature{Forwarding transactions}
Discuss has no provision for forwarding transactions between meetings,
except for writing out the text into a file, and manually entering it
in another meeting.  The Discuss client should have some way of easily
forwarding a transaction, or a chain of transactions, between
meetings. (1/4 day)

\feature{In-reply-to not bounce if no transaction}
The {\tt dsmail} program currently fails and bounces a message if the
{\tt In-reply-to:} field refers to a transaction that does not exist.
This occurs when a message is sent to multiple Discuss meetings,
with a transaction number in the {\tt In-reply-to:} field for one of
the meetings.

This bug should be fixed. (1/8 day)

\feature{In-reply-to syntax include meeting name}
If a message is sent to multiple Discuss meetings, there is no way to
specify what meeting the {\tt In-reply-to:} field refers to.  If a
transaction is listed, the entered transaction is either mis-chained
in one meeting or bounces (see above).  

{\tt dsmail} should be fixed up to accept meeting names in the {\tt
In-reply-to:} field.  The syntax should be human readable, such as ``[0100]
in Discuss\_development''.  The meeting long name or short name should
be acceptable, and multiple transaction numbers for different meetings
should be accepted.

The emacs interface should be changed to generate this syntax. (1/4 day)

\feature{Chaining by subject for mail}
{\tt dsmail} only chains new messages if they contain a transaction
number in the {\tt In-reply-to:} field.  If the message senders are
not aware of the Discuss archive, then no chaining will occur.

There should be an option for {\tt dsmail} to chain transactins based
on subject.  Mail messages on the same topic tend to keep the same {\tt
Subject:} field, and dsmail should chain transactions if it finds a
subject match in the last few transactions of a meeting.  A
transaction number in the {\tt In-reply-to:} will override this
option, and messages without subjects will not be chained. (1/4 day)

\feature{Easier mail feeds}

To set up a mail feed into a Discuss meeting, the aliases file for the
Discuss server currently needs to be changed to add the pipe into
{\tt dsmail}.

It would be nice if the sendmail config file on the Discuss server
supported a syntax to feed Discuss meetings.  Mail sent to a certain
type of address would automatically be fed into the appropriate
meeting using default options to dsmail.  Users could then add this
address string to mailing lists, without having to change the aliases
files on the Discuss servers.  A possible syntax for the addresses
would be:  {\tt ls.discuss@picasso.mit.edu} would enter a transaction
into the meeting {\tt /usr/spool/discuss/ls} on {\tt picasso.mit.edu}.
(1/4 day)

\feature{{\tt dsmail} not truncate mail headers}
Currently {\tt dsmail} only enters the first line on a mail header into the
discuss meeting.  {\tt To:} fields or {\tt Cc:} fields that span
multiple lines are truncated, so that readers of the Discuss meeting
do not have a complete list of recipients.  This is a slightly
annoying bug.

{\tt dsmail} should be fixed to display headers that span multiple lines.

\feature{Follow {\tt .meetings} symlinks}
Because of the way Discuss updates the {\tt .meetings} file, the {\tt
.meetings} file cannot be a symlink to another filename.  Although
a user can specify a real destination with the MEETINGS environment
variable, this works differently than most other dot-files in the
Athena environment.

Discuss should follow symlinks when updating the {\tt .meetings} file.
(1/8 day)

\feature{Fix delay with finding current transaction}
If a user has not gone to a Discuss meeting for a long time, the
highest transaction he read may be deleted.  If this is in a long run
of deleted transactions, it may take a long time to find the next
non-deleted transaction.

This delay should be reduced, by being smarter when searching for the
next transaction.

\feature{Fix {\tt dsc\_setup} when {\tt .meetings} is not writable}
If the user's {\tt .meetings} file is not writable for some reason,
like losing authentication, the open fails and the user is asked to
run {\tt dsc\_setup}.

The error message and behavior should reflect the lack of access. (1/8 day)

\feature{Quiet meetings}
Currently, all meetings in the user's {\tt .meetings} file are checked
when doing a {\tt check\_meetings}.  Users sometimes read meetings that
they do not want to always keep current on.  Deleting and adding these
meetings is inconvenient.

Discuss should allow users to keep meetings in the {\tt .meetings}
file that are not checked by {\tt check\_meetings}.  These will be
called ``quiet'' meetings, and marked by a ``q'' in meeting lists.
The flags field in the {\tt .meetings} will store this flag. (1/2 - 1 day)

\feature{{\tt list\_acl username}}
To list the access of a single user, the user must be specified by
username and realm name.  This is hard to type.

The realm name should default to the local realm when listing the
access of a user. (1/8 day)

\feature{Short names for {\tt -flag\_set}, {\tt -flag\_reset}}
The -flag\_set and -flag\_reset options used for selecting transactions
are hard to type, with both a ``-'' and ``\_'' character.

These options should have short names without underscores. (1/8 day)

\feature{Transactions as a short help name for transaction\_specifiers}
To get help on how to specify transactions in the tty client, you must
type ``help transaction\_specifiers'' or ``help specifiers''.  This is
difficult for users to remembers.

``help transactions'' should work.

\feature{Listing transactions by date, etc}
Currently there is no way to select transactions according to criteria
other than flag states, transaction numbers, or chains.

Transactions should be specified by additional criteria, like authors
or dates.  Some of this requirement will be addressed by previous
requirements, like searching of meetings on server, or named flags. (2 days)

\feature{{\tt print -by\_chain}}
When printing or writing transactions, there is no way to print out a
range of transactions organized by chains.  This alternate way of
displaying transactions would make it easier to follow the threads of
conversation in a Discuss meeting.

This feature should be added to the Discuss tty interface.  When the
user specifies the {\tt -by\_chain} option to the {\tt print} or {\tt
write} commands, the command should print out an entire chain it
encounters one. (1 1/2 days)

\feature{Announcing meetings on someone else's behalf}
When user accounts creates a meeting on someone else's behalf, they
usually announce the meeting in one of the public announcement
meetings.  Occassionally the accounts consultant gets questions about
these meetings, even though the meeting is chaired by somebody else.

There should be a way to explicitly announce a meeting on someone
else's behalf, and the meeting announcement should contain the name of
this individual, so that questions about the meeting are directed to
the correct place. (1/2 day)

\feature{Removing one's own chairman access}
There is a safety feature in Discuss that prevents meeting chairmen from
removing their own chairman access to the meeting.  This is to prevent
situations where no one is the chairman of the meeting.  When accounts
consultants create a private meeting, they want to remove their own
chairman access to it, but cannot because of this safety feature.

This safety feature should be changed to allow chairmen to remove
their own access, providing that somebody else would still have
chairman access.  This command should be confirmed before executing.
(1/4 day)

\newpage
\section{Features to be implemented if there are resources}

\feature{Host byte-order independent meetings}
Meetings are currently stored in a byte-order dependent manner.  This
means that meetings cannot be moved easily between Discuss servers
with different byte ordering.  Also, some users want to have insecure
Discuss meetings stored in their own file space, but the byte-order
dependency is a big obstacle for this.

The Discuss servers should be able to deal with meetings of either
byte-order.  The Discuss meetings have version numbers stored in them,
and it should be easy to detect byte-swapped version numbers.  Having
meetings stored in user local space will not be implemented for the
moment, due to the security issues involved. (2 days)

\feature{Run external program when transaction gets entered}
There is no way for a Discuss meeting to feed a mailing list.  It
would be convenient for a Discuss server to be able to automatically
run a program when a transaction is entered, which could then send it
out on a mailing list, or update another database.  For the mailing
list approach to work, {\tt dsmail} needs to be able to detect this
situation and not enter this mailed transaction again, otherwise a
mail loop will occur. (1 day)

\feature{Better handling of over-quota condition}
If the user is over quota when updating the {\tt .meetings}, the
Discuss client will not properly inform of this fact, but will simply
not update the {\tt .meetings} file.

The Discuss client should report the over-quota condition to the user.
(1/2 day)

\feature{Ignore blank lines in {\tt .meetings} files}
The {\tt .meetings} file is an ASCII file that users occassionally
edit to change the order of meetings, or manually add meetings.  If
the user accidentally adds an blank line to the file, the Discuss
client will complain about the file format and not work.

The Discuss client should be more tolerant of blank lines. (1/8 day)

\feature{Have a way to tell who set the flag on a transaction}
There is currently no way to tell who set the flag on a transaction.
For task meetings which make heavy use of flags, this is a piece
information that users would like to know.

There should be a convenient way to record this information.  Because
of the meeting format, it is not easy to add arbitrary amounts of
information to existing transactions.  Instead, the command language
for turning on and off flags should be extended to automatically add a
log message for who changed the flag.  Then users of tracking meetings can
use this language to easily log these changes. (1/4 day)

\feature{Better ``rn'' interface}
Some users prefer single-character command interfaces along the lines of the
news readers like {\tt rn}.

Although creating an entire new tty interface using single-character
commands would be too much work, some benefit would come from
extending the current ``rn'' mode for Discuss.  This is a command that
automatically walks through changed meetings, with ``rn''-like key
sequences.  Adding a few requests would not be that difficult. (1/2 day)

\feature{Better error indications of bad server setups}
When setting up a new Discuss server, the administrator needs to be
careful about directory ownership and acl files, otherwise meeting
creation will fail with an ``Invalid access'' error.  This error is
ambiguous and indicates several possible conditions.

The Discuss server should be changed to give more precise information
about what the problem is.  This would make it easier for new
administrators to set up Discuss servers. (1/4 - 1/2 day)

\feature{{\tt move\_meeting} command}
Currently, the only way of changing the order of meetings is to
manually edit the {\tt .meetings} file.  If the user makes an error,
Discuss will not be able to read the file.

There should be a move\_meeting command to move individual meetings to
specific places in the {\tt .meetings} file, so that users can easily
control the order of meetings. (1/2 day)

\feature{{\tt sort\_meetings} command}
Users may wish to sort their meetings by either short name or long name.
The Discuss user interface should have an easy way of sorting
meetings. (3/4 day)

\feature{Change OLC to use author field}
The OLC logs currently store the name of the user in the transaction
Subject field.  If this were stored in the soft author field, then
there would be more screen space to display the description of the
question.  

Once Discuss allows searching of the soft author field, the OLC
logger should be changed to use the soft author field. (1/2 day)

\feature{{\tt announce\_meeting} that automatically enters transaction}
When reannouncing a meeting, the text of the announcement is usually
stored in the first transaction of the meeting, or in a previous
announcement. (1/2 day)

The {\tt announce\_meeting} command should allow the text of the announcement
come from a transaction.  If the transaction is an announcement, the
announcement text should be stripped off. (1/2 day)

\feature{Fix up {\tt write} command}
The syntax of the {\tt write} command in the tty interface is confusing,
especially when the file name is omitted.  The syntax should be fixed
up to be cleared. (1/2 day)

\feature{Ability to find out space used by meeting}
There is no easy way for a chairman to find the amount of space a
Discuss meeting is using, or how much space an expunge would free
up.  Space management on Discuss servers would be easier if the
chairmen could keep better track of these numbers.

The Discuss server should provide a way of presenting this information,
either by keeping track of space as transactions are added and
deleted, or by providing operations that calculate these numbers. (1/2
- 1 day)

\feature{Man pages for discuss server programs}
There is currently no man pages for some of the Discuss server utility
programs, such as {\tt mkds}, {\tt recover}, or {\tt expunge}.
Minimal man pages should be written documenting these commands. (1/2 day)

\feature{Document DISCUSS\_EDITOR variable}
When the tty client edits a new transaction, it looks at the
DISCUSS\_EDITOR environment variable.  This should be documented in the
discuss man page, or the Discuss User Guides. (1/8 day)

\section{Features that should be left to other projects}

\feature{Mail transaction in tty interface}
Since Discuss is often used to archive mailing lists, it would be
convenient for users to be able to reply to the mailing list from within
the Discuss tty client.  This would allow the usual mailing features
of including the original message, replying to all recipients, and
adding the proper {\tt In-reply-to} field to get proper chaining in the
Discuss meeting.

This feature involves building the functionality of a mail sending
program into Discuss.  Discuss users use a variety of mail readers,
and the Discuss interface will be different than their usual mail
sending commands.  The Discuss client would also need a way of knowing
the mailing list address associated with the meeting, to set up the
initial {\tt To:} field. (2 days)

\feature{Flagged message in mail}
When mailing to a list archived by a Discuss meeting, it would be
convenient to be able to set the Discuss flags in the message header.
A new message header, such as {\tt Discuss-flags:}, could be used to
list the named flags that should be turned on when the transaction is
entered. (1/2 day)

\feature{Included {\tt .meetings} file for security, etc}
Currently, all the user's meetings are stored in a single {\tt
.meetings} file.  Some users may wish to separate public and private
meetings into two {\tt .meetings} files, and set the file protections
accordingly.  Being able to include a {\tt .meetings} file in another
one, or maintain two files, {\tt .meetings} and {\tt
.meetings.private} would make it easier for users to attend private
meetings without restricting access to their entire {\tt .meetings}
file. (1 day)

\feature{Setting {\tt .meetings} file}
Some users may wish to maintain multiple {\tt .meetings} files for
different sets of meetings, and be able to switch the file from within
the Discuss client.  The quiet meeting requirement, listed above, may
reduce the demand for this feature. (1 day)

\feature{Make {\tt lsm -user <name>} or {\tt lsm -public} work}
The original design of Discuss allowed the {\tt list\_meetings} command
to refer to list other users' lists of meetings, or a public list of
meetings.  In the Athena environment of attachable user lockers, this
no longer works the same as time-sharing systems.  The Discuss client
could call {\tt attach} or use AFS semantics to locate other users'
{\tt .meetings} files, and make these commands work again. (2 days)

\feature{No core dumps on bad acl file}
Discuss acl files are text files that can be edited if necessary.  The
first line is a count of entries, following by the entries themselves.
The {\tt cacl} file is in the same format, controlling who can create
meetings on a Discuss server, and must be edited by hand.  The Discuss
server will core dump if the acl file is bad, such as having an
improper count.

The Discuss server should be more tolerant of errors. (1/2 day)

\feature{Manually resetting connections in clients}
The Discuss client maintains connections to the different Discuss
servers with which it is communicating.  If one of these servers goes
down, the user will have to quit the Discuss client to reestablish a
connection.  The Discuss client should have a way of manually
resetting the connection. (1 - 2 days)

\feature{Printing out remaining number of transactions in print new}
When printing new, the Discuss client should display the number of
transactions left.  This feature will not be easy to implement if
deleted transactions have to be taken into account;  the client will
have to count up non-deleted transactions in the range. (3 days)

\feature{Built-in pager to back up}
The Discuss client uses the {\tt more} command as the default Discuss
pager, by feeding the transaction text as standard input.  {\tt more}
does not allow users to back up in this mode.  Although the alternate
pager {\tt less} allows users to back up, most users do not use {\tt
less}. 

The Discuss client should allow users to back up when reading
transactions, either by using its own pager, or writing transactions
to a file before running {\tt more}.  Adding a pager to Discuss would
require a large amount of development time.  Writing transactions to a
file before running {\tt more} will cause a significant delay when
reading transactions. (5 days)

\feature{Command history}
The tty Discuss client should maintain a command history so that the
user can go back and redo previous commands.  This would make it
easier to enter repetitive or similar commands.  

Discuss uses the ss library to implement the command-line interface.
The ss library would have to be changed to use a history mechanism,
and interpret the escape sequences to access the command history.
This is a major addition to the ss library. (1/2 day)

\feature{Support discuss meetings in WAIS}
The Wide Area Information Server (WAIS) Project is an experiment in
automating the search and retrieval of many types of electronic
information over wide area networks.  It provides a standard protocol
of obtaining information based on keywords.  It would be nice to allow
users to access the contents of Discuss meetings using WAIS.  This
would expand the distribution of text stored in Discuss meetings, and
allow the Information Retrieval (IR) techniques in WAIS to be used to
search Discuss meetings.

Supporting WAIS would involve major effort;  this is an entire new
protocol, based on text indexing.  To do it properly, a Discuss
meeting would need to maintain an text index on its contents, so that
WAIS users could quickly find relevant transactions.  Although the
WAIS distribution contains code to perform this function on text
files, changing it to understand Discuss meetings would not be easy.
(10 - 15 days)

\feature{Redesign {\tt .meetings} for seen/unseen transactions}
The {\tt .meetings} file currently keeps track of the highest
transaction seen in a meeting.  If a user skips a number of
transactions, those transactions are essentially marked as ``seen''.

Discuss should keep track of whether individual transactions are seen
or not.  This would involve changing the {\tt .meetings} file format
to contain an arbitrary amount of information regarding the state of
all transactions.  Although tracking ranges of transactions should
cut down the amount of information, Discuss must allow for the general
case.  This is a major change to the {\tt .meetings} file, and
requires changing a large amount of code. (5 - 7 days)

\feature{Subject/author based kills}
In discussion groups, certain topics or authors start to generate
relatively less useful information.  Usenet allows users
to set up ``kill files'', which automatically avoids messages from
certain people or on certain topics.

Discuss should have a similar capability, controlled by some user kill
file. The Discuss user interface would need a way to interpret the
user kill file, and apply it to the set of transactions to print.  The
user would need some way to override the kill settings when displaying
given transactions.

Since only a few Discuss meetings get transactions with low information
content, this feature has limited usefulness relative to the cost of
implementing it. (5 days)

\feature{Sets of transactions, either locally or globally}
Discuss should allow users to keep track of a selected set of
transactions, either locally to the user, or globally to all attendees
of the meeting.  The named flag feature seems to accomplish the latter
for a limited number of sets.

Implementing this feature would either involve changing the {\tt
.meetings} file format, or having Discuss access other files for
tracking Discuss transaction numbers.  Either way would involve a lot
of work, with unclear benefits. (3 days)

\feature{Check meetings in parallel}
The Discuss client currently checks meetings one at a time for all
servers.  The check meetings operation would be faster if multiple
servers were checked in parallel.  This feature would involve adding
the check meetings logic into the Discuss library, and use
asynchronous calls to check when to receive the replies and make new
requests.  While this would bring speed improvements, it is not easy
to implement. (5 days)

\feature{Expiring transactions}
Discuss transactions are stored in a meeting until a user manually
deletes them.  For meetings that store recent mail messages, older
messages should automatically expire and be deleted in some fashion.
This could either be a function of the Discuss server, or a utility
program that searches for transactions older than a given time and
automatically deletes them. (2 days)

\feature{Expunge as a remote operation}
To expunge a Discuss meeting, the administrator of the Discuss server
currently runs a program on the Discuss server itself.  It would be
nice if a meeting chairman could expunge a meeting remotely.

The expunge operation copies the meeting, and requires an adequate
amount of free space to hold the new copy of the meeting.  The meeting
chairman should have some way to find the amount of free space on the
Discuss server to know if an expunge will work.  Multiple chairmen
could expunge meetings at the same time, causing the expunges to fail.
These types issues should be resolved before remote expunging is
enabled. (2 days)

\feature{Way of setting Zephyr-flag from a program}
There is a per-meeting option to enable or disable Zephyr
notifications for a Discuss meeting, although the only way to set this
option is by manually editing the meeting file with {\tt adb}.  There
should be a way to set this flag remotely, or have a user friendy
utility that sets it. (1/2 day)

\feature{Speed up expunges}
The expunge process is currently optimized for correctness rather than
speed, causing expunges of large meetings to be a time-consuming
process.  With careful programming, the process could be sped up. (3 -
4 days) 

\feature{Deal better with expunging a full partition}
Expunging a meeting makes a copy of the meeting on the same partition
as the original.  If a Discuss server fills up a partition, freeing
up space is a challenging procedure.

There should be an easier way for dealing with a full partition.
Either the expunge process should use temporary space from a different
file system, or provide a mechanism for temporarily moving some
meetings to another file system. (1 day)

\feature{Ability to override acl's without editing manually}
If the chairman of a meeting is unavailable, the only way of changing
the access of a meeting is manually the acl file for the meeting.
While this is not especially difficult, it is an annoyance, especially
with the count of acl entries in the acl files.  There should be a way
for a Discuss administrator to override or set an acl without editing
the acl file itself. (3/4 day)

\feature{Mac Discuss client}
The Mac Discuss client should become a supported client, and the
current bugs and user interface problems fixed up.

This task is too large to be considered part of this project. (15 days)

\feature{PC client}
There should be a PC Discuss client.

This task is too large to be considered part of this project, although
porting the tty interface over to DOS might be easier than having a
graphical user interface. (60 days)

\feature{Statistics (counts) on searches}
When specifying transactions based on flags or contents, there should
be a way of just getting the count of transactions that match the
criteria, rather than a listing of the transactions themselves.  One
way of implementing this is the ability to redirect a listing of
transactions to a file, so that the word count {\tt wc} can be used.
(2 days)

\feature{Chains as trees}
Discuss currently keeps track of transactions as linear lists of
replies.  If a discuss beings to fragment into a number of related
topics, it would be nice if the transactions were organized into a
tree.

This would complicate the user interface and methods of organizing
transactions.  Also, it seems difficult enough to get users to
reply to transactions to form chains;  it is not clear how many could
deal with tree structures. (7 days)

\end{document}
