The Virtual Collaboratorium (tm)

Pete Beckman, Todd Green, Juan Villacis

This research is supported in part by: NSF CCR-9527130

Sharing and collaborating via the Internet took a giant step forward with the popularization of the Web. Suddenly, anyone with a Web browser had easy access to files, documents, and programs located around the world. However, the Web is currently very one-sided. It permits anyone with a Web browser to be an information consumer, and those with access to a Web server can become publishers. Unfortunately, simply publishing information is insufficient for real collaboration on a project via the Internet. Collaborators need an easy and secure way to share and trade files, documents, and programs. The current techniques, anonymous FTP and mime-encoded email are poor at best. Easy-to-use collaboration via the Internet requires designing and implementing a solution from the ground up, not retrofitting email, anonymous FTP, WWW forms, and cgi-bin scripts. The solution is the Virtual Collaboratorium(tm) from the Extreme! Computing Laboratory at Indiana Univerity.

The Collaboration Server

At the heart of the Virtual Collaboratorium is the server. To facilitate collaboration, the server must do more than simply push documents across the Internet to the client. The server must also have secure mechanisms to accept new documents and make them available for republication via a standard Web server or to members of the collaboration via the server. The Virtual Collaboratorium Broker Daemon (VCBD) (the server) is designed to be modular; different services can be plugged into the basic daemon as methods for collaboration, grow. The VCBD uses a collection of fast databases to represent collaborations, users, and mutually shared objects. The object-oriented, C++ interface to the Virtual Collaboration Database (VCDB) is compact and easy into use, permitting developers to extend the VCBD with their own modules. The VCBD operates much like the Unix inetd. Collaboration clients initiate a session with the VCDB, and are authenticated, and then the connection is passed to another program.

Concurrent Versions System (CVS)

The most important partner modified for use with the VCDB is CVS. CVS is a publicly available revision control system built atop the standard Unix RCS (Revision Control System). It is designed to permit several people to modify and merge shared documents or source code. CVS recently added a client/server protocol whereby a remote client could modify the CVS repository where the shared documents are stored. However, the current version requires each user to have an account on the server, or all share a single account on the server Collaboration must be possible without asking the superuser to create accounts on the server for each member of the collaboration. This is where linking CVS to the VCBD provides a clean solution. After connecting to the VCBD, which can authenticate collaboration members, clients can interact with the CVS repository, the CVS wrapper can check read/write permissions on the CVS repository and pass commands to the CVS program. Proxy changes to the repository on behalf of a collaboration member correctly maintain CVS and RCS logs, i.e. a history of each member's contributions can be extracted from the log files. Modifications to shared documents and source code by members of the collaboration are version-safe, with a complete history and backtracking available -- perfect for groups of people all contributing on a project. Combining the VCBD with CVS creates a shareable collaboration server that can act as a repository for storing documents and software in a secure version-logging framework.

Inside the Virtual Collaboratorium

The figure above shows the major components of the VC. There are three basic objects: collaborations, users, and mutually shared objects. The VC caretaker is responsible for creating new users. Users may modify their current information, such as email address, home page URL, icon, etc. The caretaker may grant some users permission to create collaborations. When a user creates a collaboration, she becomes the leader, and may add users to the collaboration. Members of a collaboration may then add mutually shared objects to the collaboration space. Two mutually shared objects are included in every collaboration, a membership list, and a mailing list. The membership list object can be viewed by all collaborators. The leader of the collaboration may edit the object by adding or deleting members. The leader may also give some members permission to create new mutually shared objects. The creator, or owner of a mutually shared object (SMO) is responsible for granting read/write permissions to the object. For example, a SMO representing a research paper may be set up to be readable by the entire collaboration, but writable only by the authors. This heirarchy of add/delete and read/write permissions permits collaborators to interact and a share their work in a flexible environment.

Graphical User Interface

The client's access to the collaboration server must use an intuitive, easy-to-use graphical interface. Currently, there are three important client interfaces being designed: Virtual Collaboratorium Administration Tools, CVS, and mailing lists.

Virtual Collaboratorium Administration Tools

The Virtual Collaboratorium administration tools permit caretakers, users, and collaboration leaders to modify the Virtual Collaboratorium Database. Interacting with the server requires no client-side data, and is therefore perfect for Java. By writing the administration tools in Java, anyone with a Java-enabled Web browser can begin to use the collaboratorium. The design on the Java interface to the Virtual Collaboratorium is still underway. Several of the Java compontents have been created, and the mock-up shown below shows the current state of the design process.

It is important to note that the mock-up, done with Java, is not yet linked to the server. To link the Java mock-up with the VCBD, the applet must open a socket to the server, authenticate, and then carry on a dialog with the server-side application that interfaces with the Virtual Collaboratorium Database. That code is still being written.

A Graphical User Interface for CVS

The client-side interface to CVS is equally important. Users of CVS report that while extremely powerful, its command-line interface and default actions are often counter-intuitive. There are several simple GUIs for CVS written in Tcl/Tk. However, all provide little real improvement to the command-line interface. This portion of the project has two goals. First, design and create a specification for an intuitive GUI for CVS. Second, implement that GUI using several techniques, including: Java and a client-side CVS, Tcl/Tk and client-side CVS, and stand-alone Java.

The first implementation will require a client-side version of CVS be present. Even with a GUI written in Java, there must be some mechanism for local files and directory trees to be modified in conjunction with the data stream to the CVS server running on the remote machine. Rather than start by reimplementing the CVS client in Java, Java will interact with a local copy of CVS which can be the client communicating with the CVS server. This will make the initial prototype easier to develop. Furthermore, as resources permit, a Tcl/Tk interface to client-side CVS will also be developed. This permits CVS users not interested in collaboration software to use the GUI designed for this project without setting up the VCBD. The final stage of client-side CVS software will be a version that needs no external CVS client. Rather, it speaks directly to the CVS server socket connection, and creates and modifies the local filesystem. Below are several of the Java compontents for a CVS GUI pasted together in a mock-up. Currently, the file browser for the local file system is working, and does indeed allow browsing a directory and file tree. However the other components on the mock-up are not working, and are shown for the layout only. It is important to note none of the Java code has been connected to the client-side CVS yet.

See cvsClient for a fully working demo version of this tool.

beckman@extreme.indiana.edu

Last updated: Tue Jan 26 17:15:51 1999