Authors and Student Researchers:
Michael E. Locasto
Michael Hulme
Justin Tracy
Ryan Gladysiwiecz

Advisor:
Dr. Ursula Wolz

Abstract:

This document describes both the project aims and requirements as well as giving a full technical explanation of each piece of the software.

Clay is an architecture that allows content developers simultaneous, real-time editing access to the same documents. It encourages developers to work together in a collaborative environment and provides guidelines for enforcing logical constraints on developer interaction. Clay is constructed of an extremely diverse set of technologies, with Java acting as a common platform and a transportation mechanism (RMI). This allows us to concentrate on defining the high-level interaction of the clients rather than low-level protocols.

The Clay software grew out of the need to provide a team of physically dispersed software developers with the ability to work cohesively on various coding projects. This initial goal provides the motivation for Clay's strong incorporation of traditional solutions (chat, bulletin boards, email, and whiteboard) to problems facing current software collaboration efforts. However, the Clay model has always kept in mind the objective for any type of document to be the focus of collaboration. As a consequence, the Clay architecture is highly extensible and distinctly flexible.

Table of Contents

Introduction and Executive Summary

We anticipate extending Clay to handle different types of documents beyond the current "text document" implementation. New clients will be capable of handling different types of media, like graphics and music. In addition, we plan to improve on the design stages of system software projects by creating clients that deal with workflow design and visual code design.

4 REFERENCES:
http://www.tcnj.edu/~assistf/clay

1. Lee, Byong G., Kai H. Chang, and N. Hari Narayanan. An Integrated Approach to Version Control Management
   in Computer Supported Collaborative Writing. Auburn University. 1998.

2. Prakash, Atul, and Hyong Sop Shim. DistView: Support for Building Efficient Collaborative Applications
   using Replicated Objects. University of Michigan. 1994.

3. Dourish, Paul and Victoria Bellotti. Awareness and Coordination in Shared Workspaces. 1992.

Concepts, Motivations, and Goals

CONCEPT INTRODUCTION

Clay is an interactive, secure, and flexible architecture for collaborative development of team projects over a network connection. While the original plan for Clay's development was applicable only to software developers, the system is easily extendable to other fields of work with varying goals. Clay is written in the Java language and, while not being the fastest and most efficient language, it is utilized because of its easy integration into web-based applications and protocol. Clay's design consists of an n-tier networking system consisting of lightweight clients. It melds together useful technologies involving networking, database programming, and RMI, and provides an easy-to-use GUI for efficient development of collaborative systems.

The initial problem faced by students here at TCNJ is pronounced in collaborative efforts to produce programs of high caliber, while restricting the group to meeting at limited times to get "back on the same page". This proves to be very time-costly, and frankly, annoying. Research shows that working as a team will provide a better understanding of the task at hand as well as a more robust end-product, and when applying this to the field of computer science, this can be seen easily. For programmers to work efficiently, they need to understand the task at hand and understand what others will be doing concurrent to their own development. An environment that will provide this will enlighten the whole team and instill a sense of confidence in which every team member will understand each other and their programming ideas.

Since this problem originally was faced by our own group of researchers in developing this project, we were able to capture the distinct levels of the development of a large-scale product. With this we saw the need for additional methods of teamwork, and additional needs for our product to have. While developing a product, there is much coding; however, we also can not ignore the amount of research and design which precedes the implementation. There should be a way for people to synchronize design ideas as well as implementations.

In addition the problem is extendable to other fields of work. For instance, a local school district and its teachers would like a way to communicate after hours to design lesson plans and re-coordinate a curriculum for their students. Currently, they have few tools to accomplish this unless they all sit in the same room with each other. Musicians, because of the rapid expansion of online music creation and sharing, will need to take advantage of network connectivity in new ways. A possible application of Clay assists them with this task.

The answer to the problem is CLAY. Clay is structured to provide an architecture to accomplish the goals at hand for any group desiring the ability to work in teams without meeting face to face. Clearly, Clay can also be a supplement to face-to-face meetings. Clay can effectively speed up the turn-around time of projects without losing the importance and scope of the tasks at hand.

APPROACH AND UNIQUENESS

The CLAY architecture is programmed in Java. Java is useful for its extendibility, and cross-platform application. The system consists of a centralized server waiting for connections from clients. Users connecting to the system login to their group project via this lightweight client, and are logged in to an environment that they may easily communicate with others in their group.

The communication between clients and server takes place completely transparent to the user. It utilizes the RMI (Remote Method Invocation) package developed as part of the Java API. The client application is designed for maximum plugability with different (and multiple) interfaces available to each group. In addition, administrator tools exist on 2 levels for ease of management of the groups, as well as members within the groups.

The components of this project are broken down into 5 major sections, despite the blurred lines between each section and the dependencies on each.

1. SERVER:
   The server system involves the actual implementation of the RMI. rmi developer quick link

   The server's job is to provide an efficient pathway between multiple clients. We have accomplished this by building a main server that will hold a pool of miniservers. It is these mini-servers which provide a client with communication abilities.

   The server also includes an interface with which it will talk to the client. Java interfaces contain no executable code, however, will set up the framework for clients to communicate with the server and each other. They will allow common client frames to talk with each other, while protecting non-matching clients from communicating.

   The server variables are stored in an XML configuration file for ease of changing data without changing code. This could allow minor system changes without a system overhaul (or even a recompilation of code).




2. DATABASE SUPPORT:

   There are two systems which fall into this category. The first will be a true database which will handle user logins, group logins, and store user preferences. In addition it will contain the permissions which every group and user can have. Permissions include: group leader, contributor, admin)

   The schema which was set up follows:

   
   Connection String:   jdbc:postgresql://159.91.48.101:5432/claydb
   User Name:   postgres
   Password:    postgres70
   
   Schema:
   
   
   
   	Table1: ClayUser
   	- username    varchar(30)  Primary Key
   	- firstname   varchar(20)
   	- lastname    varchar(20)
   	- password    varchar(20)
   	- affiliation varchar(100)
   	- isLoggedIn  boolean
   	- chatFgColor varchar(7)
   	- chatBgColor varchar(7)
   
   
   
   	Table2: Projects
   	- name        varchar(100)
   	- id          autoincrement integer Primary key
   	- summary     varchar(500)
   	- status      varchar(20)
   	- startdate   varchar(20)
   	- enddate     varchar(20)
   
   
   
   	Table3: UserProjects
   	- username  varchar(30) foreign key
   	- id        serial integer foreign key
   	- isAdmin   boolean
   
   	

   The database was implemented in PostGreSQL 7.0 on a Red Hat Linux 7.0 (kernel 2.2.16-22) system.

   The second system is a CVS (Code Versioning System). This controls the file versions which people will be committing to, and allows group members easy control over who may edit a particular file. The CVS is a directory structure, and can keep folders of previous versions as well as the current.
   
   

3. CLIENTS:

   (see the design:client types section for full detail)
   
   

4. ADMIN TOOLS:

   Administrative functions are held on two levels. The first level will be standard programmer. The second level will be within each group. Group members hold certain functions for the group, primarily the job of "committer". The committer will have the final say on what gets saved for good in the project.
   
   

5. HARDWARE:

   The needed hardware is minimally a Pentium-2 class processor at 350 MGz or faster. The different pieces of Clay may reside on different machines but these locations should be reflected in the XML configuration file. In addition, the software was built to function with a Java Development Kit of 1.2 or greater.

   • RMIRegistry
   • Clay Server
   • Project Servers
   • Database server
   • Http server
   • Application server
   • Firewall(s)
   • CVS server

Design Specifications

The following sections detail the exact design of each of the pieces of the application. Additional information is available in the Appendix and at the website.

Main Clay Server

The Clay server is responsible for startup and shutdown tasks and managing connections to the pool of ProjectServers. Upon starting, Clay will attempt to read the clayserver.xml XML configuration file for other relevant startup information not included in the clay.bat run script.

The XML config file contains entries for logging mechanisms, database connection pool startup information, project server information, client interface information, general RMI connection information, and information needed by the CVS.

The Clay server is an RMI application; this means it is made available via the RMIRegistry. It indicates that it is by extending class UnicastRemoteObject. In addition, it implements the ClayRMIServer interface, which is an interface we wrote to define the methods avialable via RMI calls to the object.

	
	public class Clay extends UnicastRemoteObject
                  implements ClayRMIServer {
	
	

In addition to its startup duties, the Clay server maintains a Hashtable of ProjectServers. These ProjectServers are keyed in the Hashtable on the Project name. Should Clay find discrepancies between the XML config file and the database, it will not start that particular ProjectServer. In other words, it will create a ProjectServer if and only if both the XML config file and the database agree.

Clay makes itself available via RMI with the following instructions:

		
		if (System.getSecurityManager() == null)
		    System.setSecurityManager(new RMISecurityManager());

		    try {

		            ClayRMIServer clayRmiServer = new Clay();
		            clayRmiServer.execute( args );
		            String clayServerName = "//"+serverInetAddress+":"+port+"/ClayServer";

		            Naming.rebind(clayServerName, clayRmiServer);
		            System.out.println("Clay Server bound.");

		        } catch (Exception e) {
		            System.err.println("Clayserver exception: " +
					e.getMessage());
		            e.printStackTrace();
		        }
		
	

Note the use of the RMISecurityManager. One of the key points to be addressed in the Clay software is the use of the Java2 policy file security implementation. This is often a stumbling block in applications that attempt to actually use Java security measures. The learning curve for the Java2 policy file security implementation is quite steep, and doesn't allow as fine-grained a control as some would wish. However, it is an excellent tradeoff and when used properly, it will not cause headaches.

Note also the way Clay is constructed. A new "Clay" object is constructed but is bound in the RMI Registry by its RMI interface name, ClayRMIServer.

Project Servers

Clay maintains a pool (Hashtable) of ProjectServers. The project server is responsible for the transmission of both the original document and any DocumentEvent objects from the clients connected to it. Below is the method in Clay that allows a client to retrieve an reference to the appropriate ProjectServer. Keep in mind the "ProjectServer" object is actually the RMI Interface to the ProjectServer_Impl object that contains the actual definitions to the RMI methods as well as other capabilities not specified in the RMI ProjectServer interface.

	
	public ProjectServer getProjectServer( String username,
						String password,
						String projectId,
						ClayRMIClient clientRef )
		 				throws RemoteException;
	
	

The ProjectServer encapsulates the ability to transmit and keep a record of changes to any of the documents currently under editing consideration. The ProjectServer also contains a reference to an AuthAgent object, which provides the ProjectServer with the ability to authenticate clients logging in.

During the design of the client interaction and the ProjectServer, we were afraid that a DocumentEvent would infinitely propagate and reflect from any client to all others because of the nature of the DocumentListener interface and the relationship between the Client and the GUI it was listening to. However, with the Proof of Concept (see Appendix), we determined that this would not be a problem.

Clay Environment

The Clay environment and architecture (as detailed graphically in the Appendix) follows closely the architecture for the Jakarta-Tomcat project. This structure (the file structure) is typical of current Java applications, and not something unique to either Clay or Tomcat. It is simply the best current way to set up a Java application. However, the class hierarchy and application architecture of Clay is unique.

Clay contains a conf/ directory for configuration files, a src/ directory, containing the current frozen source files for that release, a lib/ directory to hold the compiled Clay server itself, a www/ directory where the stubs can be downloaded from. It also includes some other directories for documentation and logging, and a bin/ directory for compilation and startup/shutdown scripts.

The Clay environment contains some general utilities:

• a JDBCConnectionPool
• JDBCConnectionPoolFactory (static singleton structure)
• a Logging interface and ClayLogger class
• a ClayException for specialized error and exception handling.
• custom compilation and startup scripts. (generally useful for any complex java project) These are needed because of the intense amount of work needed to configure the environment to run an RMI application.

I. Connection Pool

Connection pooling is the process of pre-allocating database connections and recycling them as new clients are connecting or reconnecting. This is needed because of the high overhead of connection creation and the high connection rates typically encountered when using databases. With a connection pool present, the high overhead is limited to the first few seconds of the server starting up, and allows faster transfers of queries.

Within Clay, the connection pool is used in three separate instances. First, the main Clay server establishes the connections to the project servers, and allocates how many servers there should be. Second, the connections to the database to authorize users reside in a second connection pool. Third, the web based applications use a connection pool to quicken the transfer over the web.

The ConnectionPool class is a general utility within the Clay package. The key main functions of the utility are: pre-allocation of connections, managing available connections, allocation of new connections, waiting for available connections, and closing existing connections.

The utility also needed to be smart enough to know when available connections needed to be closed out because there are too many available, and when there would be a strong need for more in the near future. While this is hard to actually predict, the utility does attempt to shrink and expand its pool to match a demand given to it. As calls for more connections come in, the class will increment its available connections by 5. This will ensure that there will always be available connections for requests, as well as keep overhead to a minimum. In addition, the class controls how many available connections that are unused, and tried to limit them by closing them out.

The physical components of the class contain vectors to hold the connection objects. There is maintenance of an available vector, as well as a busy vector. You will be able to set the initial connection limit, the max connection limit, and the timeout rate through an XML file.

II. Interface to the client

It is extremely important for the clients to have a common interface/protocol to be able to easily send through the server. This has resulted in a java abstract class (interface class) listing the basic methods to send information between clients. The definitions to send documents, as well as support for the chat functions reside here, and future clients will have to extend this class as they write their own client and client interfaces.

The class consists of methods to handle the client's username and password for security purposes. It also has chatrecieve(), chatsend(), and chatBroadcast() declarations to handle the chat component. The most important method declarations are the receive methods. The capacities to send documents and document events are shown here. Documents are the heart of the projects that users work on.

Each of these methods is representative of the major components within Clay that will be represented graphically and are central in the GUI.

III. Clients (Present and Future)

The current client is a robust GUI interface that can handle many types of data. It implements a single interface (see II), and has the ability to handle additional interfaces easily. Currently only a coding document interface is implemented successfully.

The coding agent in the client is a useful utility to program multiple code files within a project structure. A user may open any number of files from the server or their local machine, and upon completion of the file, "commit" the document to be saved to the server. In addition to this, the main JTextArea contains multiple document listeners and can show other coders' progress working on the same file that you are viewing. While the updating of the document will be done in real time, it will not be constraining and overly distracting. In addition, the code is syntax highlighted via XML, which can mark code as Java, HTML, C++, etc.

The client contains a chat feature for real time typing and conversation outside of the working window. This can be useful for typing to single users or broadcasting to all users. We envision the window to be used for discussion of the project, coordination of user jobs, and the archived listing of ideas and contributions from separate users. While this is an important piece of Clay, the technology is not new. However, we hope that the uses for this technology will evolve.

The client is also able to spawn windows other than one in which to code. These are not implemented as of yet, however are designed on paper, and listed here as a general overview:

• In order to improve communication between group members working on a project, one of the most important steps in completing a project is the design phase. In answer to this, the client will contain a designer where users can visually lay out the project. In addition, these visual representations will output code to match the skeleton of the project. This will be separate from the actual coding module because of the intense graphic needs that must be run separately from the coding document. We feel that visual coding will be a very important part of the future, and this is our motivation behind the feature.
• A GUI-designer will be made to enable easy-to-build front ends to projects in development. As in the designer, code will be outputted from the designer to match the GUI, therefore eliminating countless hours of code fiddling around with code. This feature is in its infant stages.
• A whiteboard-type of application to allow group members to communicate with each other visually. This application will utilize simple drawing tools to represent ideas, but will not have the overhead of containing code-writing features.

An additional feature to the clients will be the limiting of user permissions on data. A vital use to this would be the ability to hold meetings between developers and clients for which the developers are working. Permissions can be set so that certain users can only view data, instead of writing out to it. It is hoped that business conferences would be successfully run through this technology.

User Management and Usability

User Management

This portion of the project allows the system administrators and project administrators to take control over the system and the individual projects that are running on the system. It allows system administrators to control the project administrators and furthermore, it allows project administrators to control the end users that have access to any of the active project.
This portion of the project utilizes the following technolgoies:
JSP
Javabeans
Servlets
Connection Pool
SQL
and of course HTML

The implimentation of this portion of the system was quite straight forward. First off, the Connection Pool is a running thread constantly active in Tomcat. The Connection Pool is activated on start up by using the web.xml file to call a servlet that forks this thread. The Connection Pool is used to have a persistant connetion between this application and the database, dramatically reducing the cost of connecting to the database multiple times. Using this pool, the JSP code connects to the database and preforms its duties of add, modify and delete. This three commands are the backbone of the User Management System. They allow for all the functionality that is needed to administrate this system and are presented to the user in the most logical and usable manner. System Usability

A fundamental reality of application development is that the user interface is the system to the users. What users want is for developers to build applications that meet their needs and that are easy to use. Too many developers think that they are artistic geniuses - they do not bother to follow user interface design standards or invest the effort to make their applications usable, instead they mistakenly believe that the important thing is to make the code clever or to use a really interesting color scheme. Interface design is important for several reasons. First of all the more intuitive the user interface the easier it is to use, and the easier it is to use the cheaper it is. The better your user interface the less help people will need to use it, reducing your support costs. The better your user interface the more your users will like to use it, increasing their satisfaction with the work that you have done. The point to be made is that the user interface of an application will often make or break it. Although the functionality that an application provides to users is important, the way in which it provides that functionality is just as important. An application that is difficult to use won't be used. It won't matter how technically superior your software is or what functionality it provides, if your users don't like it they simply won't use it.

Here are some issues to keep in mind when designing a good user interface:

• Visibility of system status
  The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
  
• Match between system and the real world
  The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
  
• User control and freedom
  Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
  
• Consistency and standards
  Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
  
• Error prevention
  Even better than good error messages is a careful design which prevents a problem from occurring in the first place.
  
• Recognition rather than recall
  Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
  
• Flexibility and efficiency of use
  Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
  
• Aesthetic and minimalist design
  Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
  
• Help users recognize, diagnose, and recover from errors
  Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
  
• Help and documentation
  Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

Content Management and Version Control

The CVS

The Concurrent Versions System or CVS is an integral part of the CLAY architecture, providing a well managed storage system for projects and documents. The CVS maintains a central repository of data, though it is often used to store and organize source code, it is not limited to this type alone. It is able to store any ASCII file and is able to handle binary files as well, though the cost of doing so is slightly more.

The CVS delivers functionality that allows users to track different versions, know when the last modification was made on the data and by who, merge several different checked out copies into a single master copy, and many other manipulations of data. The basic idea behind the CVS is that users check out a working directory and check in new versions of files. On older versions of the CVS, only one user could check out a particular working directory at a time, but newer versions allow multiple users to check out the same working directory. Likewise, older versions were not able to merge checked in documents, while the newer versions support this functionality.

The ability for developers to have access to the same code deposit and be able to track version numbers and modifications simplify the task of collaborative development on projects. The CVS is a powerful tool when used correctly and allows developers that are physically separated to work together as a team without having to deal with the overhead of managing multiple versions and file assignments.

The CVS can be used over a networked environment and the most efficient way of doing this is by using the CVS-specific protocol. Developers have implemented CVS server/client packages that utilize the CVS-specific protocol and allow easy interface with the Data Repository.

CLAY utilizes the CVS by incorporating a CVS Client connection to a CVS Server within the CLAY Main Server. This connection is passed to the spawned Project Servers. Project Clients that are connected to the Project Servers are able to request an action from the Project Server and, permissions from the Project Client being valid, the Project Server will execute the request on the CVS Client that has the connection to the CVS Server. In this manner all of the Project Clients will seem to have a CVS Client, but in reality only the CLAY Main Server has the Client and the Project Servers are the only ones able to execute commands on it and the only way for these Project Servers to execute commands is through a Project Client with the proper permissions.

To manipulate a CVS, developers use special CVS Clients that connect to special CVS Servers. The CVS Server maintains the repository. The CVS Clients connect to the CVS Server through one of several ways. After connecting, the CVS Client must authenticate itself to the CVS Server. After this is done the CVS Protocol is started. The CVS Server sends responses to the CVS Client only when there is a request from the CVS Client. Since the CVS Server only responds when the CVS Client sends a request, the connection is governed by the CVS Client.

When the CVS Client is finished authenticating, it transmits Valid-responses request to let the CVS Server know what responses the CVS Client supports and Valid-requests request to find what requests the CVS Server supports.

CVS Client - General Protocol Conventions

• Entries Lines - transmitting RCS data
• File Modes - read, write, execute, etc…
• Filenames - conventions regarding file names
• File Transmissions - how file contents are transmitted
• Strings - strings in various requests and responses
• Dates - times and dates

CVS - Protocol

Requests - list of requests

Requests that begin with a capital letter do not execute a response from the CVS Server, while all others, with the exception of 'gzip-file-contents', do. Unrecognized requests always execute a response from the CVS Server.

Response Pathnames - The "pathname" responses

After a request that requires a response, the CVS Server sends however many of the valid responses are appropriate. The CVS Server should not send data at any other time. All responses end with 'error' or 'ok', indicating the end of the response.

JCVS

While searching for information on the CVS and ways of implementing it, we came across this CVS Client Package done completely in JAVA. Information can be found at http://www.jcvs.org/.

This package, developed under a GNU license, incorporates a way to communicate with a CVS Server. By creating an instance of this client on the CLAY Main Server and passing the connection to the Project Severs, we will be able to utilize the CVS.

The JavaDocs for this package can be found at: http://www.gjt.org/javadoc/com/ice/cvsc/ - client/server protocol http://www.gjt.org/javadoc/com/ice/jcvsii/ - client application

Appendix

1. Figures detailing the Design of Clay

2. Proof of Concept

   The two proofs of concept demonstrate the feasibility of the Clay software, as well as conclusively showing that we will not run into a readers/writers problem. The first proof of concept is an implementation of a Java RMI application. The second proof of concept is a simple GUI demonstration of the mechanism that clay will use to synchronize clients and documents.

   Java RMI Application
   Because the code is long and involved, only significant portions are included. In addition, most of the code and architecture was adapted from the Java Tutorial RMI Trail.
   

   DocumentEvent Mechanism
   The code presented here is made up of three classes: a main GUI, a client class, and a server class. In Clay, the clients and servers will be in different Virtual Machines.

   	
   	import javax.swing.*;
   	import javax.swing.event.*;
   	import javax.swing.text.*;
   	import java.awt.*;
   	import java.awt.event.*;
   	import java.util.Vector;
   
   
   	public class Test2 extends JFrame{
   
   		private JTextArea ta1;
   		private JTextArea ta2;
   
   		private DocumentListener tac1;
   		private DocumentListener tac2;
   
   
   		public Test2(){
   
   			super( "DocumentListener testing with Server" );
   
   			Container c = getContentPane();
   
   			c.setLayout( new BorderLayout() );
   
   
   			ta1=new JTextArea( "", 10, 30 );
   			c.add( new JScrollPane( ta1 ), BorderLayout.WEST );
   
   			ta2=new JTextArea( "", 10, 30 );
   			c.add( new JScrollPane( ta2 ), BorderLayout.EAST );
   
   			RServer server = new RServer();
   
   
   			tac1 = new Client( ta1, server );
   			tac2 = new Client( ta2, server );
   
   
   			//tell ta1 to notify tac1 of any changes in ta1
   			ta1.getDocument().addDocumentListener( tac1 );
   
   			//tell ta2 to notify tac2 of any changes in ta2
   			ta2.getDocument().addDocumentListener( tac2 );
   
   			setLocation(10,20);
   			setSize( 600, 600 );
   			show();
   	}
   
   
   	public static void main( String [] args ){
   
   		Test2 t = new Test2();
   		t.addWindowListener(
   			new WindowAdapter(){
   				public void windowClosing( WindowEvent wevt ){
   					System.exit( 0 );
   				}
   			}
   		);
   	}
   
   
   	}
   
   	class RServer {
   
   		Vector clients;
   
   		public RServer(){
   			clients = new Vector( 10 );
   		}
   
   		public void login( Client c ){
   			clients.addElement( c );
   		}
   
   		public void broadcast( Client c,  DocumentEvent de ){
   
   			for( int i = 0;i<clients.size();i++ ){
   				Client temp = (Client)clients.elementAt( i );
   				if( temp != c ){
   
   					if( de.getType() == DocumentEvent.EventType.INSERT){
   						temp.remoteInsertUpdate( de );
   					}else if( de.getType() == DocumentEvent.EventType.CHANGE ){
   						temp.remoteChangedUpdate( de );
   					}else if( de.getType() == DocumentEvent.EventType.REMOVE ){
   						temp.remoteRemoveUpdate( de );
   					}else{
   						//throw exception
   					}
   
   				}
   			}
   		}
   	}
   
   
   	class Client implements DocumentListener{
   
   
   		private JTextArea canvas;
   
   		private RServer s;
   
   
   		public Client( JTextArea j, RServer server ){
   
   			canvas = j;
   			s = server;
   			s.login( this );
   		}
   
   
   		public void remoteChangedUpdate( DocumentEvent de ){
   			canvas.setDocument( de.getDocument() );
   		}
   
   		public void remoteRemoveUpdate( DocumentEvent de ){
   			canvas.setDocument( de.getDocument() );
   		}
   		public void remoteInsertUpdate( DocumentEvent de ){
   			canvas.setDocument( de.getDocument() );
   		}
   
   
   		public void changedUpdate( DocumentEvent de ){
   			s.broadcast( this, de );
   		}
   
   		public void insertUpdate( DocumentEvent de ){
   			s.broadcast( this, de );
   		}
   
   		public void removeUpdate( DocumentEvent de ){
   			s.broadcast( this, de );
   		}
   
   	}
   
   

3. Source Code

   The full Clay package, with all source code, is available on the website. Follow the links for the Clay releases.

4. A Note on Scope Creep

   Any serious [and some not-so-serious] software developers* know well the demon called Scope Creep. The Scope Creep demon is a creep indeed. His attack is a sneaky one; the infection often occurs as the result of well-intentioned additions to the software under development. Scope Creep occurs when functionality tends to get packed into an application not for any business case or reasonable need; rather, the software starts to include the feature or technology "because it can" or "because that would be cool."

   This is a deadly occurrence that must be avoided at all costs. Deadlines, if they matter to you at all, [not a common occurrence with those we've lost to the Zen] will be blown away, delayed, or pushed back. Following the SLC can limit the infection Scope Creep brings, but does not make the project immune. Make sure you have well-defined functional requirements and write a full design document before you start to code in earnest. Further functionality can always be included in later versions of the software.

   One common complaint of developers is that they hate to write design documents: they argue that such a detailed document is a useless duplication of effort. Writing a full English (or whatever language) description of what you are going to code and then writing that code, complete with internal documentation is akin to performing the same task twice. Many would rather code first and document later. This approach is faintly reminiscent of the "shoot first and ask questions later" approach. Do not fall into this trap! Scope Creep is highly attracted to such a cavalier [and hubristic] attitude. My answer is that coding can be split into two parts: initial fussing about and implementation of key features, [which becomes the basis of the design document] and the complete, exhaustive, and careful construction of fully internally commented code. This allows your design document to become a living document that has a stable core [the key features] and various refinements [construction of the software details].

   Scope Creep occurs for any number of reasons. Often it rears its ugly head because the developer, as they become more familiar with the features of the API or technology they are using, feels inclined to include these features in the software they are developing. This results in the "because that would be cool" phrase being employed. On the other hand, developers who utter the "because it can phrase" is an incantation that the Scope Creep demon loves to hear because it means that the developer has become careless and is not likely to examine his own motives too closely. This results in a disastrous possession by the Scope Creep demon. Prayin' won't do you no good at this point; your soul is lost.

   *I distinguish between programmers and developers. Any monkey with a decent programming book can write code. Developers are those programmers who make an effort to create original and useful generic pieces of software or programming projects. Developers will often see code as an art form; programmers see it as a set of instructions, no different than a manual for washing dishes. Do not let yourself become dispassionate and numb and degenerate into a mere programmer! Scope Creep, however, happens just as easily with developers as with programmers. It is a demon to be feared across the board.