CS190 - Project Requirements
Christopher Filippis (cjf)
2/2/00

Overview:

In today's world of telecommuting, open source projects whose authors are
separated by thousands of miles, and large group projects (such as the
ones in this class), it becomes more and more desirable to have an easy
way of communicating and exchanging ideas without meeting in person.  As
it is right now, there are only a few programs (at least, free programs)
that allow for much more than IRC chat, which has been available for
decades now.  With the advent of webcams and high bandwidth connections,
software has been developed to communicate across the Internet, but can
not usually go for much more than a one on one session.  This proposal is
to create an application that will allow large scale collaboration of many
people at the same time with tools that will allow the easy exchange of
information.

Target Users:

The target user is one who works in groups remotely over the Internet.  It
can be for graphics professionals who wish to work on enhancing a picture
together.  It can be used as a general enhanced chat room.  It can also be
used for programmers of large software projects.  Thus, we the programmers
can act as one of target users for project, but its power should not be
focused on programming alone.

Requirements:

Base system:

Server - Client setup
The program will be broken initially into two parts, a client and a
server.  The server will act as a central connection point for
distributing all of the information to the clients as well as receiving
input from the clients to redistribute.  The server is meant to be
persistent, thus allowing someone to log in to the system at any time, and
not forcing the starting user to be present for the entire meeting. 

Voice Chat
Bandwidth is becoming great enough today to allow the use of voice in a
modern collaboration program.  This would work well for small groups of
people so they can keep their hands free for other tasks.  The voices
would be superimposed on one another as they are streamed in, and then the
sum of the voice lines is streamed back out to each of the clients.

Text Chat
While mostly trivial to implement, it is still an important addition to
the program to ensure compatibility with systems that don't have an audio
card, or people who don't have a microphone, or simply large groups where
the audio would get too garbled with so many people in the room.  It can
also be used easily over low bandwidth connections.

Whiteboard
This should be a fairly simple drawing tool that all users can see at the
same time.  Draw commands will be on the level of something like Microsoft
Paint, so they can be kept fairly simple and thus transferred quickly and
efficiently over the connection in an event based system rather than pixel
by pixel copies.

Application Sharing
X-Windows has the unique ability in that it can broadcast its clients to
remote computers using plain old TCP/IP.   In this way, the client and
server can act as a "proxy" for transmitting the TCP display information
from a client program to the server, and then rebroadcast it to all of the
X-Servers that the clients are running on.  In this way, one person can
open up an application and everyone can see it on their own machines.

Simple News Group Messaging System
While the intention of this project is not to write a full NNTP server, it
would be nice for people to be able to be able to log into the server, and
upon finding no one there, leave a message for all to read.  Thus, a
simple message system should be implemented where a user can post a text
message to the users of the software.

Login Procedure
A name/password should be used for most systems to provide a modicum of
security so not everyone would be able to access the system, or so one
person could not masquerade as another.

Personal Info
The server should also be able to contain a set of information about the
users, so that one could get in contact with them when they are not in the
forum.  This would simply be a list of email addresses, phone numbers, and
snail mail addresses which the user elects to put into the system.

Calendar
A simple calendar should also be included to write in appointments, and to
schedule meetings.  Submissions can be made by any user, and the sysop can
review and change them if need be.  The news group can be used to discuss
meeting times before hand.

Cross Platform Compatibility
While it would be unfeasible to make this into a windows executable, it
would be nice to make this project compatible with all Unix systems, thus
allowing more potential users of the system.  One such possibility would
be Linux, which has gained a fair bit of popularity among programmers of
late.  Thus, it would be good to have this system use Unix standards
rather than proprietary Solaris capabilities, and to make it compilable
under Gnu gcc rather than just CC.

Optional Additions:

Multiple Rooms
The server can be extended to have multiple meeting occurring at the same
time through the use of "rooms" in which the users in one room do not hear
or interact with the users in another room.

Compressed Audio
To allow this system to work in a lower bandwidth environment with voice
chat, audio compression can be implemented to squeeze a high quality
signal across a small pipe.  The MPEG Layer 3 audio specification is an
open standard which has available source code, and can compress audio down
to 1/16 of its original size without any significant loss in quality, and
would probably make a good addition to the project (and not for background
music :) 

Multiple Simultaneous Users of Shared X-Clients
The base specs allow for a program to be viewed by many, but only
controlled by one.  While this may be a desirable mode of operation for
certain situations, it would be nice if all people could manipulate the
program at the same time.  Thus, multiple streams of input data would need
to be processed and parsed by the server so that they can all be
recombined into one stream for the actual X-Client to receive.  Then,
everyone would be able to control the single X-Client.

High Security Protections
This is pretty self explanatory, and can be applied to everything from
encrypting the user's password using a public key / private key system, or
even encrypting the data stream so that a rogue user could not listen in
on a private discussion.