% % 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 } 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}