Figure 4-1 The Architecture of DCWA.
Computer systems, especially software systems, have long been designed as stand-alone entities. Software packages for one-user use have dominated almost 100% of the software market, but this situation has begun to change. In the foreseeable future, a new generation of distributed computer software geared for supporting collaborative work is expected to flourish. The success of this new generation of software is now almost certain because the underlying principle for the software (namely, allowing multiple users to contribute to the same piece of work any where and any time) is welcomed by users. Moreover, the fast advances in computer networks have laid solid technological foundations for making this new generation distributed software systems possible.
Research into the possibility of these exciting software systems, widely known as computer supported collaborative work (CSCW) systems, started about ten years ago. Numerous commercial and experimental systems have been designed including a system called DCWA for collaborative writing applications [Chang95].
From our experience working in the area of CSCW research and development, we have come to realize the possibility and the potential significance of CSCW systems in engineering design processes. An engineering design process normally involves a great deal of discussions, cooperations, as well as individual efforts. It roughly undergoes the following steps:
Note that the above steps may not be followed strictly in all engineering design processes. In some areas, prototype testing is more emphasized than simulation such as VLSI design, but in some areas, prototypes are impossible or too expensive to make. A typical example is the design of large telecommunication networks for which no prototypes can be made. Another example is the design of an emergency evacuation system for an aircraft whose testing requires emulating emergent situations which may destroy the prototype thus making the testing costly. In both cases, computer simulation may be a feasible, reliable, and cost-effective means to circumvent the impossibilities.
In the computing history, CPU (Central Processing Unit) speed doubled every 2.5 years (i.e., in recent years chip performance doubles every year); the CPU cost decreased linearly [Hennessy 90]. In addition, in about every ten years, a new generation of computer architecture arrived because of the emergence of revolutionary technologies, resulting in ``quantum leaps'' in chip speeds. The increasing computing power and decreasing costs of computer systems contribute to the fact that computer simulation has now become an important step in the design process on which more and more engineering designers rely. There is no doubt that computer simulation will gain more importance and popularity in engineering design process in the future.
The objective of the project is to develop a CSCW environment to support engineering design, specifically, a distributed environment that combines computer aided design (CAD) and computer aided software engineering (CASE). In an effort to combine them into a seamless engineering package, we first target at supporting engineering designs (using CAD) with computer simulations (using CASE). The success of combining design and simulation will pave the way for possible future investigations with virtual reality, hardware interfaces for specialized engineering devices, knowledge bases for specific engineering problems, etc. Therefore, the impact of this project is not only confined within the design and simulation software.
While supporting engineering design processes using CSCW tools is an emerging concept, to combine design and simulation in a distributed environment is a new idea. Computer simulation is an important tool in almost all engineering areas for evaluating quality of designs. Appropriate use of computer simulation requires training on the designers because a gap exists between a design and its simulation --- mathematical modeling and computer programming are, therefore, needed to bridge the gap. For a large design involving a group of engineers, the modeling process requires frequent discussions, clarifications, and redesigns. The programming phase will generate additional such needs. To enhance productivity in such an environment, a CSCW tool which can provide
These objectives have been achieved by integrating the state-of-the-art technologies, including high performance workstations, high speed computer networks, distributed multimedia database, and graphical user interface. The CAD component of the system supports drawings of 2D objects by a team of geographically distributed designers. Object hierarchies and integration constraints among various components can be agreed upon and imposed with the help of real-time discussion facilities. The CASE component supports members in their writing of simulation code for individual components, and then combines separate components into an executable program through an object-oriented approach.
The project development has been primarily based on a CSCW prototype, called DCWA (Distributed Collaborative Writing Aid) [Chang95]. The purpose of the DCWA is to support a group of users in the process of composing a document, e.g., a paper, a manual, a program, etc. The necessary extensions to achieve the new objectives include a redesign of graphical user interface, improvement of collaborative text and graphics editors, provision of video and audio discussions, redesign of the multimedia database, and conducting field tests.
The remainder of this report is organized as follows. Section 2 presents a general survey of the CSCW field with emphasis on collaborative writing and drawing tools that are closely related to DCWA. In Section 3, a summary of the main features of DCWA is provided. Section 4 discusses the system structure and the group management approach. The main graphical user interface of DCWA, called Logical View Editor, is presented in Section 5. Section 6 describes the needs and approaches of the search and semantic network tools. Section 7 contains the detailed description of the fundamental communication class utilized in this system. The interactions among group members can be achieved through the video conferencing facility of DCWA, which is presented in Section 8. In order to integrate the contributions from members for either documents or software, a document integrator and a software integrator/simulator have been developed. They are described in Sections 9 and 10, respectively. Section 11 provides a complete sample run of the system. Section 12 describes the software and hardware platform under which DCWA is developed. Finally, Section 13 presents the file structure of the software that has been made available in a repository, which a user can access through ftp.
In a conventional problem solving environment, computers normally provide passive support to a group of users working as a team --- while computers store, analyze, retrieve, and present data, the decision process governing the logical and orderly interactions among team members is left to the users. As the pressure of improving productivity continues to grow, new technologies must be developed to provide active support for cooperations and to overcome geographic barriers [Cuena93]. This demand leads to the recent research and development of CSCW [Power93, Diaper93, Hewitt93, Sharples93]. The collection of hardware and software supporting CSCW and the like is also known as groupware [Orr92] in the literature.
Centralized groupware (i.e., either large mainframes or PC based system) was explored in the past as a means for achieving office automation [Grudin94]. Only recently, the focus has been shifted to the development of networked distributed groupware [Grudin94]. Many problems remain open in a distributed environment. The most salient ones are the group management, multicasting, distributed database management, and user interface. These problems are mutually dependent and cannot be dealt with in isolation. In this section, we introduce the reviewers to some well-known CSCW systems.
2.1 Synchronous Group Conferencing
Synchronous group conferencing (i.e., all participants are active and instantly aware of events that happen in the system) has been accomplished through multimedia communication channels. The MERMAID [Watabe90] and the SPIN [Palmer93] systems are prototypes that provide real-time conferencing environments for geographically distributed participants by using synchronous textual, audio, and video communications. In addition to providing conferencing service, the COGNOTER system [Stefik87] also collects and organizes ideas from its participants for discussion.
CoSARA is an environment that allows users to construct the system architecture of a synchronous conferencing application [Berson94]. The environment is based on the so-called Object World (OW) mechanism. The CoSARA provides a global conference server and several local conference managers that handle the initiation and termination of a conference, joining and leaving a conference, and the management of strongly shared conference data. The global conference server also maintains a list of all active participants. The local conference manager provides tools for graphical editing, and it displays broadcast messages. The graphical editor is used to build the framework (or block diagram) of the application by linking various objects provided by the OW. The OW has several advantages: it allows the users to determine the degree of sharing that will be used as well as the granularity of the shared operations. However, the OW has several disadvantages. First, the authors mention slow performance. Second, the OW is written in LISP, and any application to be run on top of the OW must be written in LISP as well. Rewriting these applications may prove to be time-consuming.
2.2 Collaborative Writing
In the field of collaborative editing, the collaboration among co-authors can be classified into two categories: shared mind and division of labor [Sharples93]. In the first category, multiple authors edit the same file at their own locations and one coordinator integrates the contributions. In the latter category, a task is divided into mutually independent subtasks for co-authors. These classifications are in parallel with the notions of synchronous versus asynchronous collaborations. In the synchronous approach, users work at the same time on the same file, while in the asynchronous approach, users may not work at the same time.
The well-known rIBIS [Rein93] and the SEPIA [Haake92] are synchronous hypertext systems providing various modes (levels) of collaboration. In the independent mode, users may work on their own tasks without interfering with each other. In the loosely-coupled mode, users may share certain public information while working on their own tasks. In the tightly-coupled mode, users will share the same view, but resources, e.g., mouse and file, are strictly controlled to avoid conflicts.
An interesting observation made in [Diaper93] is that the success of collaborative editing depends heavily on the mutual confidence and trust among team members. We believe that the mutual trust among authors should increase when communication facilities are conveniently available.
2.3 Collaborative Graphics Drawing
One of the pioneers for CSCW graphics environment comes from the Wang laboratories, called Freestyle [Cooper91]. Graphical images are brought into the system from screen snapshots and hand-drawn images (which may be scanned in or faxed). Users can use an electronic drawing pad to annotate images on the screen; the images can also be annotated with voice messages which can be played back at the touch of a button. All Freestyle images are stored as bitmaps. The resulting work can then be e-mailed to other users. The system does provide users with some CSCW capabilities, but due to its use of e-mail as the means for communication, it does not support concurrent graphics editing capabilities.
One effort of allowing multiple users to perform concurrent graphical operations in a distributed, networked environment is the TeamWorkStation (TWS) [Ishii91]. Its design is based on a real-time, openly shared workspace which every member can see, point to, and draw on simultaneously by using a variety of drawing tools. TWS provides a translucent overlay of individual workspace images. This is accomplished by superimposing images created at different sites. These images can be created in several ways. One is by means of a graphics editor; another includes a touch pad located on the desktop. Yet another method is the use of pen and paper on a desktop with a video camera filming the process. TWS uses four separate communication media --- video, data, voice, and input device.
There are several problems inherent in the use of the TWS approach. One is that results of the collaboration can not be shared directly. In other words, users can not directly manipulate each other's work without using the tightly coupled mode (which has large response delays). Another is that the graphics quality of the overlaid image is not as sharp or stable as that of conventional graphics programs. This can be detrimental if highly detailed drawings are necessary. A third problem is that when more than three users are at work, it is difficult to identify the owner of an object. Another disadvantage is that scrolling or moving an object may destroy its spatial relationship with other objects. Finally, two screens, a telephone, and two cameras at each node as well as a special video server and four communication media make the acquisition of such a system costly.
A collaborative graphics editing tool called, GroupPaint, is based on the DEEDS client-server model Liang94] . The model consists of a groupware server, an application server, and a client. GroupPaint was derived from the Microsoft Windows Paintbrush program. The painting results are stored and manipulated in the form of bitmap. By superimposing bitmaps, group collaboration may be achieved. The application server for GroupPaint provides coordination among multiple users. First, it provides an empty workspace to each user. A user is given full read/write privileges in his own workspace. He can also view the contents of other users' workspaces, but cannot write to or modify another user's workspace in any way without authorization from the owner of the workspace. The GroupPaint application server can also combine the work of several users. It does this by overlaying the images created by all the users.
GroupPaint has several advantages. First, it provides better graphics quality than the TWS approach. Second, it allows no conflicts such as two users trying to modify the same object. It does, however, allow users to modify each other's work (assuming permission has been given). Third, there is no high equipment overhead such as the requirement for multiple media; the whole application was done on PCs over an existing LAN. Another advantage is that it is easy to identify the owners of other work, even when many users are involved, because the work of other users can be viewed in separate windows. GroupPaint, however, has several weaknesses. One is that it does not provide good communication facilities such as voice or face-to-face communication. This may hamper the whole objective of group collaboration. Another flaw is that GroupPaint provides no facilities for maintaining spatial relationships. That is, if a user decides to move an object he/she has designed, other objects attached to it will still stay at their original locations. That may result in objects ``floating'' in space.
Ensemble is an X-Window based, object-oriented graphics editor [Montes92]. Concurrency is controlled by the so-called implicit locking. When a user loads a file, he may then create an object or select an object to edit. A lock is then placed on that object. If a user attempts to select an object that has already been locked, he is informed that the object is currently selected by someone else. Although a user is able to see other users' pointers on screen, other users' editing sessions cannot be seen.
Ensemble has several advantages. One is that users can share the results of their collaboration, and those results can be stored as files. Another is that Ensemble handles all the locking; a user does not have to explicitly lock out an object from other users. Thirdly, the system is fast. All graphic windows are run locally, and updates would not be made permanent before an object has been ``deselected.'' Ensemble, however, does have some disadvantages. One is that users cannot use hand gestures or see each other's faces. Another is that a user cannot observe the editing in progress. When a discussion is needed, the users would have to switch to the textual window, which was found to be cumbersome. These problems hamper the users' abilities to communicate with one another. Moreover, the system does not provide for the maintenance of spatial relationships among objects.
One important observation of these graphical editing packages is that they lack an online coordinator which can be used to support partial views of the object being designed and combine all views together into one design when necessary. Another observation is that most systems do not have built-in conferencing function. The understanding is that the conferencing capability would be supported by a separate group conferencing facility. The isolation between editing and conferencing supports may potentially result in out of synchronization between design activities and discussions. These problems will be dealt with in the proposed research.
2.4 The DCWA and this Project
The main concern of this project is to develop a CSCW environment for combined engineering applications involving both CAD and CASE. Through our investigation over the past a few years, to our best knowledge, combining both CAD and CASE into a seamless distributed CSCW environment is a brand new idea. This project has been based on our experience of the DCWA [Chang95], which addresses many issues identified in the literature. The previous version of DCWA is implemented in many standard programming facilities, including 4.3BSD Unix, the TCP/IP protocols, the OSF's Motif toolkits set, the X-library drawing primitives, the ANSI C, and C++. Portability is, therefore, automatically maintained.
The DCWA provides collaboration through the system's groups services facility. A distributed multimedia database organizes both textual and graphical information according to their organizational (structural) relationships as well as their semantical relationship. Users can manoeuvre in the document logically using a semantic network that is overlaid on the organization structure of the document. The user interface helps the user view his/her own work and other group members' working areas with either WYSIWIS (What You See Is What I See) or WYSINWIS (What You See Is Not What I See) style. The WYSIWIS style is typical for synchronous cooperation where members must see changes instantly, while the WYSINWIS style is important in case information must be tailored before being presented to a remote user. More details of the design and implementation of the DCWA can be found in [Chang95]. Although the DCWA has laid the groundwork for the project, the system was totally rewritten to provide the necessary functionality and the improved system efficiency.
For clarity of presentation, the major features of the system are summarized before the details are discussed in the following sections.
One issue that must almost always be addressed by the developers of groupware applications and suites is document security. Document security is accomplished in a variety of ways. Microsoft Office allows a user to assign a password to a document, such that only those users who know the password can access the document. In the UNIX world, file permissions allow specific kinds of access to the owner, a group, or to everyone. Both methods have their problems. Users of Microsoft Office are forced to remember passwords, perhaps a different password for each document. Applications based on UNIX platforms can try to provide some kind of security through passwords, but this does not prevent unauthorized users from gaining access to the file through some method external to the application, such as through the textedit program. Some degree of security can be gained if the user uses filemgr or chmod/chown from a shell to manually set the group ownership and permissions.
Most commercial and research groupware applications suffer from what we call the all-or-one principle. This means that either the owner has exclusive access to a document, or everyone has access to it. Systems that suffer from this principle do attempt to provide some security, but that security is not focused on document production by a limited number of users. Some systems such as DIVA do provide exclusive access to a document to a limited group of people [Sohlenkamp94] through the use of access lists, but these methods can be circumvented through methods external to the system. Groupware development toolkits such as GroupKit often provide facilities for restricting entry into a conference to an exclusive set of users [Roseman92]. These kinds of systems suffer from the same limitations as DIVA, because restricting conference entry has no effect on access to documents by methods external to the application. Other systems such as Ensemble [Newman-Wolfe92] provide server processes, like the Graphics Manager, that control access to a file, but for the purpose of concurrency control. Such systems still depend on security mechanisms, such as setting file permissions, which are external to the system and which may be tedious to use for documents consisting of a large number of subdocuments.
4.1 DCWA and Collaborations
To properly solve these problems, what is needed is some kind of method that does not rely on passwords (why use passwords when the user's identity has already been authenticated during the login process?) and that transparently sets group ownership and permissions on any document produced by collaborating members. This section describes a paradigm for providing document security through mechanisms provided by the UNIX operating system, but in a convenient and transparent way. This paradigm, known as Collaborations, has been put to practice in the prototype, called Distributed Collaborating Writing Aid (DCWA). DCWA provides a variety of tools for the production of documents by a limited group of people. In this system, writing and documents are to be interpreted in their broadest sense. Using DCWA, collaborating members can produce documents consisting of text, graphics, and images. Users can also use the CASE capabilities of DCWA to produce, organize, and test C++ code. Additionally, any document can be automatically converted to HTML format for viewing in web browsers. Collaborations provide a means for a group leader to define who will be working on a collaborative document. All access to that document (and its subdocuments) is moderated by DCWA, based on the Collaboration membership.
4.2 Collaborations
Collaborations provide a solution to the problems of groupware document security and joint access. This paradigm makes several assumptions. First, systems that follow this paradigm will typically be used to produce large documents, usually consisting of a master document with two or more subdocuments. Second, a group of collaborators will typically have a leader. All members of a collaboration will have the same kinds of access to the master and subdocuments, but only the leader can decide the membership of the collaboration. This organization is intended to reflect a typical office or development setting where there will be many collaborations with overlapping memberships, and where a single user may be a member of many collaborations.
A collaboration is defined by several components. Each will be described briefly in this section, and will be discussed in more detail throughout the rest of this paper. They are as follows:
DCWA is organized in a simple but powerful architecture that uses the Collaborations paradigm to maintain information about collaborations and to prevent unauthorized users from gaining access to collaboration documents and joining sessions of a collaborative effort of which they are not a part. This architecture can be seen in Figure 4-1. Its components and how they use the collaboration paradigm will now be discussed.
Two components of DCWA assist the user in creating new collaborations and joining existing collaborations of which they are members. These two components are organized in a client/server fashion similar to GroupKit's Registrar and Registrar Client [Roseman92]. The Collaboration Database Management System (CDMS) is a server process that maintains a database of information about every collaboration within a network domain. It accepts and processes requests from Collaboration Control Panel (CCP) clients. When a user first enters DCWA, a Collaboration Control Panel is started. The CCP provides a user with the option of creating a new collaboration, editing the membership of a collaboration of which he is the leader, starting a session of a collaboration of which he is a member, browsing all collaborations, or deleting a collaboration of which he is the leader.
4.3.1.1 Creating a New Collaboration
When a user decides to create a new collaboration, he sees the interface shown in Figure 4-2. The topmost field is where the user names the collaboration. The option menu immediately below contains a button for every UNIX group of which the user is a member; he simply chooses the appropriate group. The next region contains a modified file selection box that allows the user to choose the parent directory where the collaboration working directory will be located. The next field contains the login and domain name of the current user (this can not be modified). The last region contains two lists. The list on the left indicates the current membership. This list on the right displays all the members of the UNIX group chosen in the option menu explained previously. When a new group is selected, any previously declared users in the left list are removed, and the right list is updated to contain only the members of the current UNIX group. Because DCWA uses UNIX groups extensively to provide document security, it is important that only members of the selected UNIX group are permitted into the collaboration. The mechanism described above guarantees this.
Once the user has defined the collaboration to his satisfaction, he submits the entry to the CDMS, which accepts or denies the request. If the request is denied (this will happen if the collaboration name is already in use), a reason is given and the user is given the opportunity to correct the problem. If successful, then the CCP attempts to create the working directory and some default system files in that directory.
4.3.1.2 Starting a Session
From the CCP, the user is also given the option of starting a session of a collaboration of which he is a member. If this option is chosen, the CCP asks the CDMS for a list of all collaboration data for the collaborations of which the user is a member. Once the data is received, it is displayed in the interface shown in Figure 4-3.
Data for one collaboration at a time is displayed. If the user is a member of several collaborations, he can use the next button to advance to the next one. Once the user arrives at the correct collaboration, he can press the Start button. This will initiate a session of DCWA (to be described shortly). The most important aspect of this option is that the user can not start a session of (and thus gain access to the files of) a collaboration, unless he is a member.
4.3.1.3 Other Options
Some other options include browsing collaborations and editing their membership. A user can determine the leader, UNIX group, and membership of any collaboration by using the Browse option. The procedure and the interface are the same as when starting a session except that CCP requests a list of all collaborations from the CDMS and the user is not given the option of starting a session. This feature can be useful in that it allows a user to determine what collaborations currently exist, and who the leaders are. If the user wants to participate in a collaboration, he can ask the leader (perhaps through email) to admit him into the collaboration. The leader, in turn, can use the Edit option of the CCP to add the user to the collaboration (provided that the user is also a member of the UNIX group associated with the collaboration).
From the CCP, a user can start a session either through the normal Start Existing Collaboration mechanism, or when he creates or edits the membership of a collaboration. A separate process, called SessionStart, determines if a Collaboration Coordinator (CC) is running and starts one if necessary. Then the LvEditor is started.
4.3.1.4 The LvEditor
The LvEditor is where all document production is accomplished. It is explained in detail in [Dollar97], but will be briefly explained here. The LvEditor allows user to organize a document in a tree structure, with each node representing a subdocument. Nodes can consist of text, graphics, and code (currently only C/C++ is supported). Additionally, images generated with external applications can be included. The LvEditor also provides a node attribute editor, search and semantic net capabilities that use these attributes, an HTML document generation tool, and a video conferencing tool to support group discussion. A Computer Aided Software Engineering (CASE) tool provides a means by which code nodes can be tested individually, or selectively linked. The LvEditor also provides tools with which to edit node contents (i.e. text and graphics editors), and with which to modify the document structure itself.
4.3.1.5 The Collaboration Coordinator
Because several collaborating members can be modifying the document structure and editing subdocuments simultaneously, some sort of concurrency control is necessary. This is provided by the Collaboration Coordinator, which will now be briefly described.
As was mentioned previously, a Collaboration Coordinator is spawned by SessionStart if necessary. This is done only once, and the CC continues to run until all members have exited the system. When a LvEditor is started, it connects to the CC for the current session. Modifications made in the LvEditor to a document's structure are moderated by the CC. An implicit locking mechanism is used to ensure consistency among subdocuments. When a user selects a node, a lock request is sent to the CC. If there are no conflicting requests, the CC grants the lock and the lock information is multicast to all active members. When a local client is informed of a remote lock, the node is painted red, and his LvEditor will not allow write access to the node's contents. The user can, however, make a request to the CC for read access. The CC instructs the lock owner to start sending periodic updates to each client who wants read access. In this way, users can view the ongoing work of other users.
This section will discuss the main process through which all collaborative work is done--the LvEditor. It will also discuss the Collaboration Coordinator (CC), the process that coordinates the activities of all active Collaboration members. It will first give an overview of the groupware capabilities provided by the LvEditor. Then it will discuss how the Collaboration Coordinator ensures data consistency across multiple instances of the LvEditor. Finally, this section will describe how the LvEditor and Collaboration Coordinator address many of the concerns in a typical CSCW system.
5.1 The LvEditor
The Logical View Editor, LvEditor, is the interface through which Collaboration members work together to produce a document. It provides a number of capabilities. Users can define the structure, henceforth called the logical view, of the document being produced. Users can also assign attributes to each node in the logical view. Moreover, users can invoke text and graphics editors from which node editions can be made--as well as text and graphics viewers which display the editions-in-progress of other Collaboration members. Lastly, users can invoke, from the LvEditor, specialized features such as a node search/semantic net tool (see Section 6) , an HTML document generator (see Section 9), a CASE tool (see Section 10), and a videoconferencing system (see Section 10). The LvEditor can be seen in Figure 5.1. Each of these components will now be described.
Documents in DCWA are organized in a structure called the document logical view. The logical view is similar in principle to the outline view provided by Microsoft Word, but is displayed as a tree structure. The tree consists of nodes which can represent chapters, sections, figures, etc. in a written document, or can represent programs, modules, and functions in computer code. Tree nodes are implemented internally as the class LvNode. Class LvNode associates several attributes with each node including a node name, node type, associated file, and pointers to its LvNode parent and children.
One of the most important attributes is the node type. LvNodes can have one of the following seven types:
The logical view of a document is stored in a file with the name
When a leaf node is inserted into the tree, it automatically assumes the type PLACE_HOLDER. The user can assign a name and node type to it using the Node Attribute Editor as shown in Figure 5-3.
Users of DCWA can create and edit text and graphics subdocuments through text and graphics editors accessible from the LvEditor. These editors provide capabilities similar to other text and graphics editors, but they also have special features that work closely with the LvEditor and the communications subsystem. When the user clicks on a node in the logical view tree, the system first determines the node type. If the node is a TEXT or SIMULATION node, a text editor is instantiated; then the associated text file is loaded into the editor. For example, Figure 5-3 shows the attributes for the synchronous node, including the name of the associated file. The associated file has the same basename as the name of the node itself and a .nod extension. If the selected node is a GRAPHICS node, a graphics editor is instantiated and the associated graphics file is loaded. Graphics files created by the DCWA graphics editor are stored in DCWA graphics format (DGF) and always have a .dgf extension (Note: there are two filters to convert from DGF to X11 Bitmap and GIF formats, but there is currently no conversion from other formats back to DGF). If the selected node is an IMAGE node, the associated file is loaded into a user-specified editor. ROOT, INTERMEDIATE, and PLACE_HOLDER nodes have no associated file, so clicking on nodes of these types does nothing.
DCWA uses a locking mechanism to prevent users from editing the same subdocument at the same time. While only 1 person at a time can edit a text, graphics, or simulation node, it is still possible for other users to view the node's contents. In fact, the LvEditor allows users to view the editions to a node's contents as they occur.
The Collaboration Coordinator (CC) coordinates the activities occurring within the LvEditors of all Collaboration members during a session. A session is considered active if there is an active instance of a CC for that session, and there can only be one instance of a CC during the lifetime of a session. When a user starts a session, DCWA first determines if other members are already involved in a session (i.e. a CC for the Collaboration is running). If not, DCWA starts up a CC and then an LvEditor, which then connects to the CC. If there is already an active session, only an LvEditor is started; it connects to the current CC. The CC is active as long as there is at least one member participating in the session. When the last member exits, the CC also exits.
The CC's function is similar in principle to Ensemble's Graphics Manager [Newman-Wolfe92], but its scope and responsibility is much larger. It maintains the document's logical view (and the file where it is stored) and moderates all modification requests. It controls access to each node's attributes and subdocument. It also relays document editions from the source of the editions to the viewer(s). Each of these functions will now be described.
Distributed systems must provide some kind of concurrency control mechanism if processes share common data structures. In DCWA, all LvEditor processes in a session must share an LvNodeList, a data structure containing information about all nodes in the Collaboration's logical view. Some concurrency control mechanism must be provided to prevent LvEditors from simultaneously modifying a logical view. Shared memory can not be used because LvEditors will not typically be running on the same machine. The logical view could be stored exclusively in a file, and the file and record locking capabilities of Solaris could be used to prevent simultaneous access. This, however, will not work if members of a Collaboration reside on different file systems (a real possibility in DCWA). The only viable solution is to have a process that controls access to the shared data structure. This is the function of the CC.
One of the CC's most important functions is to maintain the collaborative document's logical view. Much as the CDMS provides the CCP with general information about Collaborations, the CC provides information about a document's logical view to the LvEditor. Moreover, it is the only entity that can actually modify the logical view and the file where that view is stored. Users make modification requests to the CC through the LvEditor. Most of the time, such requests will be honored by the CC. However, there are certain instances where conflicts can occur; the CC helps resolve these conflicts. For example, consider the logical view in Figure 5-2. When a user wants to modify the logical view, the modification must be based upon some kind of reference point so that the location of the modification can be ascertained. In this example, if the user wanted to insert a sibling node between the Intro and Taxonomy nodes, an INSERT_AFTER operation could be performed with Intro as the reference node.
Consider what would happen, however, if another user simultaneously tried to delete the Intro node. Given the unpredictability of network delays, there is no way to guarantee that the messages will arrive in any particular order. If the insertion were to occur before the deletion, no problem would occur. If the deletion occurred before the insertion, then the reference point for the insertion would no longer exist--which could lead to unpredictable results. While there is no way to prevent conflicts from occurring, it is possible to gracefully recover from them. The CC provides this graceful recovery. In the above example, if the deletion occurs before the insertion, the CC would reject the insertion and inform the requestor that the operation has been rejected. In general, when the CC receives any request to modify the logical view, it determines whether or not the modification can be performed and applies the modification if it can. If the modification can not be performed, the CC rejects the request and informs the user of the rejection and the reason for it. This prevents the integrity of the logical view from being compromised.
The CC also controls access to nodes within a logical view. The user can perform two basic requests upon a node (besides deleting it). He can edit its attributes, and he can edit its contents (i.e. the associated file). Some concurrency control mechanism must be used to prevent multiple users from modifying a node simultaneously. This is accomplished in DCWA using an implicit locking mechanism. When the user wishes to edit, for example, a text node, he clicks on the node, and a text editor is instantiated. Before the editor is instantiated, however, a lock request is passed to the CC. The CC determines if the node is already locked, and if not, it grants the lock and informs all users of that lock. If the requestor receives a message indicating that it has been granted the lock, it then brings up a text editor. When the user exits the text editor, a message indicating this is sent to the CC, which then frees the lock and informs all users.
In the logical view tree displayed in the LvEditor, nodes are colored according to their lock status. Blue indicates that the node is not locked; green indicates that the local user has the lock; red indicates that a remote user has the lock. If the user clicks on a green or red node, nothing happens. However, it is still possible for a lock request to be denied, even if the user clicks on a blue node. For example, if two users simultaneously attempt to lock a node or if a user tries to lock a node while another is trying to delete it, then the request that arrives at the CC first is honored and the second is rejected.
The CC also assists the LvEditors in sending updates to remote LvEditors. While only 1 user at a time can edit a node, other users can view those editions as they occur. Suppose that a user selects a remotely-locked node for viewing (by selecting the node with the right mouse button and clicking on View Node in the popup menu); the following sequence of events occurs. First, a view request (either TEXT_REQUEST or DGF_REQUEST) is sent to the CC, which then forwards the request to the owner of the lock. The owner of the lock then sets a flag indicating that updates for the particular node are to be sent. It then sends an acknowledgment to the CC, which updates a data structure indicating that the requestor is to receive data for the node; it also sends an acknowledgment to the requestor. The requesting LvEditor then instantiates a viewer (either text or graphics). At this point, the requestor can continue with his work and automatically receive updates.
DCWA uses a transmission-on-demand strategy--that is, the owner of a lock does not begin sending updates until it is specifically requested to do so. Each LvEditor maintains a list of nodes for which (if any) it is to send updates. Periodically (currently, every couple of seconds), it sends updates for each of these nodes to the CC. The CC keeps a list of update recipients for each locked node. When an update arrives for a node, the CC determines who is supposed to receive the update and sends the update to each of those users. Using this strategy, lock owners do not send updates unless someone wants them, and they do not have to keep track of who wants them. The CC automatically handles the routing decisions. This reduces the load on the network and simplifies the LvEditor implementation. A typical scenario is shown in Figure 5-4.
In the above scenario, if a user requests updates on a node for which another user is already receiving updates, the process is somewhat simpler. In this case, when the CC receives the request, it adds the requestor to the node's list of recipients and immediately sends an acknowledgment to the requestor. The lock owner is not involved at all in this case. When the receiver of updates no longer wishes to receive them, he simply dismisses the viewer. A message is sent to the CC, which removes the user from the node's recipient list and sends an acknowledgment. If the list becomes empty as a result of this request, the CC instructs the lock owner not to send any more updates for the node.
The logical view of a document can become very complicated as the size of document increases. In order to help a user locate a desired portion of the document quickly, a search tool must be provided. In group writing, collaborators may need to know the contents of a node written by others in order to use the node appropriately. If the node contains C program code, for example, the tediousness of the code often gives rise to the need for a reader to consult with the writer directly for clarification. An automatic search facility of the nodes' attributes would help a collaborator gain knowledge about what the others have written without having to actually read their work or ask them directly. It would also help a user quickly locate the node he wants to edit or read.
In the search tool, a user may make a queried search of the logical structure to limit his/her personal view of the structure. Nodes which meet the query criteria will be displayed in an output window. There are two types of queries, new and revised. A new query searches the entire logical view for matched nodes. A revised query only searches the matched nodes from the previous query (either new or revised). A revised query must choose one from "AND", "OR", and "NOT" options. In either case, a "Hit list" of matched nodes will be returned and is displayed on an output window. The user may make another query subsequently to further modify the view. If a query does not produce any nodes that the user is interested in, he may start over by making a new query, which searches the entire logical view again.
The search tool also provides the facility of scoping the attributes for display. For example, a user may be only interested in certain attributes such as the name and keywords of the found nodes. The user can select these attributes for display. The search tool also provides an easy-to-use GUI and a user does not need to know complicated search commands. Every search query in this tool is accomplished by a simple click of button.
The search window includes five major parts as shown in Figure 6-1, a query selection box, an attribute option_menu (popped out when clicking the button below Attributes for Query), five user input query dialog boxes, a display selection box, and a semantic network button. A user may specify a query by clicking a toggle button from the query type selection box. The user can find out the node attributes by clicking the attribute option_menu button and then choosing them from a pull-down option_menu(which contains all the attributes of nodes). The format of the display is also flexible. A user can select whatever he wants to display by selecting a single or multiple attributes from the "Display For" box. By default, if the user does not specify any query toggle button, the tool will accept the query in the "User Input Query" dialog box. The search will then be based on the query and go through all the attributes of all nodes.
Figure 6-1. Search main window
The lower part of the node search window consists of four query dialog boxes. It has two columns: "Attributes" and "Query". The Attributes column accepts selected item from the "Attributes for Query" option_menu. That is, when a user select a specific attribute from the option_menu, the attribute is passed to the "Attributes" column automatically. The user can then type in the desired value in the "Query" column. A user can specify up to four attributes in the query table. Note that, whenever the user types in a value in any one of the four boxes, its corresponding toggle button on the left side of the query table is set automatically. Thus, the tool knows which attributes should be used. If the user tries to use more than four attributes in the query table, an error message will pop up and suggest the user to "Reset(Clear)" the query table.
The bottom of the search window is a "Semantic network" button. Sometimes the node attributes alone may not provide enough information for the user. For example, consider a user constructing a user's help manual for the C program. A node may contain several child nodes which deliver various kinds of error messages. The search tool may not provide how the nodes are related to each other. With the semantic network, the user can trace related nodes that he is interested in. The semantic network can be generated and displayed by clicking the "Semantic network" button. The details are explained in a later section.
The search window is accessible through the "Node_search" button in the main logical view window. Once the user clicks the "Node_search" button, the search window pops up immediately (see Figure 6-1). A search session should proceed as follows:
Figure 6-2. Query type, Attribute, and Display option selection
To illustrate the capability of the tool, some sample queries are given in this section. For example in a coding application of C program, a section of code is designed to handle an X-window mail tool. The nodes of the section can be organized in a hierarchical logical structure. A sample logical structure is presented in Figure 6-3.
Figure 6-3. Logical Structure of mail tool
Suppose a user wishes to get all the nodes about "mail". What the user needs to do is to click the "New Query" toggle button, input the keyword "mail" and then click "Search" button. The search will go through all the attributes of each node and extract the nodes that match the user input query. The search window and the search results are shown in Figure 6-4.
Figure 6-4. Search result with keyword "mail"
Suppose the user tries to retrieve the source code about "Mail_tool" in the second search and just wants to display "Node Name", "Owner", "Topic", "File name", and "Keywords". He can type "source" in the query dialog box and select the five attributes that he wants to display from the "Display For" selection box. Because this search is based on the first search, the user should select "AND_Relation Query" button this time. The result will be displayed in a pop-up window shown in Figure 6-5. Again, if the user tries to search all the nodes about "Documentation" and append the result to the previous one, he can just select the "OR_Relation Query" button and type "document" in query dialog box. The result will be appended to the previous result. The window and results of this search are shown in Figure 6-6.
Figure 6-5. "AND" query with keyword "source"
Figure 6-6. "OR" query with keyword "document"
The user can restart a new query at anytime. Suppose the user wants to start a new query by clicking the "New query" button, and tries to retrieve the node about "Help". He can type in "help" in the query dialog box and then click the "Search" button. If the user also wants all the nodes that do NOT have the "Help" feature, he should select the "New_Not relationship" query and type in keyword "help". The results are shown in Figure 6-7 .
Figure 6-7. "NOT" query with keyword "help"
The node search tool has been successfully implemented, and it has accomplished the anticipated functionality. Its main purpose is to help a user locate a desired node in the document quickly. It makes use of the meanings (or attributes) assigned to the object structure. The attributes of the nodes can also form a semantic network which is separated from the organizational (or node) structure.
Most existing CSCW tools only allow users to associate a label with each node in the organizational structure. However, the information that can be carried by one label is quite limited, To improve this situation, node attribute/value pairs as described above were implemented. Once these attributes are given values, a search of the logical structure can be made to limit the tree to only those nodes which the user is interested in. In addition, these attributes can also be used to develop a semantic network on top of the organizational structure. In other words, it is possible to relate the nodes through inheritance structure.
For example, in the above widget code, assume a node contains all the help messages, including the error and troubleshooting messages related to the system. The following attribute/value pairs can be created for the node to indicate its subcomponents: Contains / Errors and Contains / Troubleshooting. In addition, if the user decides that "Help" is a sub-concept of "Documentation", then (Is_a, Documentation) pair can also be created. After the user has located the "help" node by using the search tool, he can click on the "Semantic net" button to generate the semantic network for node "help". The result is shown in Figure 6-8.
Figure 6-8. Semantic network of "help"
In the figure, the colored button is the node that the user has queried. In addition, its ancestors and descendents are displayed around the queried node. This relationship is fully expanded until no more related node is found. If a user want to examine the contents of any node in the semantic network, he can just click the node just as in the normal node browsing, and will see the associated window pop up. A user can continue another query by providing a different value in the search window.
By associating each node with the user-specified attributes/value pairs, a semantic network can be overlaid upon the organizational trees and can be used to define a new view for the user. Also, by combining the semantic network and the search facility, users may compose queries to locate all nodes that satisfy certain conditions. The result of the query may also be used for further search until the needed information is found.
The communications subsystem provides methods for sending many kinds of messages including system messages, audio data, video data, text and graphics updates, and many other kinds of data--all over the same channel. Because different components of the system have varying reliability requirements, the communications subsystem supports both TCP and UDP transport protocols. This section will first discuss Packet classes, the Message class, and how they use TCP to achieve reliable message-passing capabilities.
The TCP protocol provides a reliable transport mechanism that guarantees that all messages are delivered, that they are delivered error-free, and that they are delivered in the order in which they are sent. TCP does not support broadcasting or multicasting, it requires that a connection be established and maintained, and its reliability mechanisms (i.e. those mechanisms that force the retransmission of lost or erroneous packets) may impose more transmission overhead than UDP. However, in the communications between the Collaboration Control Panel and the Collaboration Database Management System, and those between the LvEditor and Collaboration Coordinator, reliability is a must. Moreover, broadcasting/multicasting is not necessary in these subsystems, and the overhead of ensuring reliability is tolerable. The videoconferencing system uses UDP because, most of the time, reliability is not necessary (steps are taken during decompression to recover from packet loss). Moreover, TCP can compromise the realtime constraints imposed upon such a system. Where reliability is needed, the videoconferencing system's messaging system uses a retransmission protocol. For a complete discussion of the use of UDP in DCWA, see [Dollar97].
The most basic element in DCWA's communication system are the packet classes. These classes, implemented in C++, encapsulate the data to be transmitted, methods for organizing the data into a transmittable string, methods for transmitting and receiving the data, and methods for extracting the data from the received string. Consider the messaging that occurs when the CDMS sends information about a Collaboration to the CCP. The CDMS keeps and maintains data about a single Collaboration in a Collaboration structure, shown below:
Because the internal representation of the components is fairly complex and involves the use of pointers, a simple write() call can not be applied to this structure directly to effect a transmission. For example,
would at the very least transmit the wrong data, and could even lead to a segmentation fault. Instead, the data must be converted into a single stream of data (including component lengths) before transmission. DCWA's packet classes do this.
In the case of the Collaboration structure, a supporting class called CollabDataPacket packetizes the data for the programmer.
The constructor for this class accepts a pointer to a Collaboration structure, and based on the data contained in that object, determines the components name_len...data (the details are fairly complex and are omitted here). At this point, the object is ready for transmission, which is handled by the send() method shown below:
When a CollabDataPacket is sent, three blocks of information must be sent--6 unsigned integers indicating the various lengths, an array of integers indicating the string lengths of the members, and the actual data string itself. (Note: these blocks could have been sent with 3 write() calls; however, the iovec structure and writev() call allow all data to be sent in a single function call, improving performance slightly).
On the receiver side, the receive method retrieves data from the network connection and constructs a CollabDataPacket from this data.
Note here that complete reception can not be achieved with a single readv() call because the lengths must be known so that the appropriate amount of memory can be allocated. Once the complete CollabDataPacket has been received, the client can use the extract_collaboration method to recreate a Collaboration object.
Consider the Collaboration Data retrieved and displayed in Figure 4-3. Figure 7-1 shows how that data is transferred between sending and receiving processes.
Figure 7-1 Sending and receiving a CollabDataPacket over a socket. The sender first creates a packet and then sends it. The first 8 4-byte blocks are unsigned integers that represent size information. The last 116 bytes represent the strings being sent. Upon reception, the receiver uses the size information to extract the various components from that 116 byte string.
In DCWA, there are many types of messages that must be exchanged. While CollabDataPacket and the other packet types could be used directly whenever needed, this can not be done without some considerable effort. For example, the CDMS may receive any one of 8 types of messages, each of which contains different types of data in different formats. The CDMS does not know in advance what type of packet may be arriving. What is needed is another message type indicating the type of message that is to follow. Thus a message indicating the type of message to follow must first be sent, followed by the message to be sent. Having to send two messages is cumbersome and will lead to runtime errors if the programmer forgets to send either message. The Message class solves this problem.
In DCWA, the Message class is actually a set of three independent classes. Each class is optimized for the particular kind of services desired. Messaging occurs between 3 different groups of processes--the CCP and CDMS, the LvEditor and CC, and between all video conference processes. Each group of processes requires the exchange of different packet types; they also require different kinds of reliability. For example, the CDMSMessage class is optimized to provide reliable message delivery between the CCP and CDMS.
In the above class definition, type indicates the type of message being sent. Time is a timestamp (not currently used). Msgdata points to the packet to be sent or the one just received. A partial definition of the send method follows:
When the application must send a message, it needs only to create the appropriate packet (discussed earlier) and call the send method of the Message class. For example, in the CCP, when the user wishes to create a new Collaboration, the CCP must send a message requesting the CDMS to add the new Collaboration to the database. This is done as follows:
CDMSMessage's send method sends the message header (type + timestamp) and automatically calls the send method of the CollabDataPacket object.
The receive function performs the inverse function:
When the receiving process knows that it has been sent a message (CDMS uses the poll() system call to determine this), it needs only to call the receive method of CDMSMessage. As shown above, the receive method reads the message header (which tells it the type of message being received), and then calls the receive method of the appropriate packet type. For example, CDMS receives the ADD_COLLABORATION message sent like this:
Because of the organization of CDMSMessage (and the other Message classes), the receiving process does not have to know in advance what message type to expect. CDMSMessage automatically takes care of this.
During development, our main goal was to create a groupware suite that supports CAD and CASE applications. Because DCWA is currently only a prototype, and some improvements are yet to be made, portability was not one of our chief concerns. Most parts of the system are inherently portable to most UNIX and X-based systems; however, to improve the efficiency of the system in some parts, we used facilities that may render the system non-portable. The system requirements are as follows:
Additionally, the user should make sure that his environment is set up for Unix/sysv instead of Unix/bsd. XIL 1.2 and SunVideo are not necessary if the videoconferencing system will not be used; Makefile.common and bin/Makefile should be modified to reflect this (see the instructions in those Makefiles).
The NIS+ name server is required by the Collaboration Control Panel (CCP). When a user wishes to create a new collaboration, he is presented with a list of all members of the currently-selected UNIX group. Unfortunately, the family of functions getgrnam(3C) do not return usernames whose primary group affiliation is the selected group. There are a couple of ways to get these users. The first is to loop through every name in the passwd database with the getpwent(3C) function, and retrieve each user whose primary group affiliation is the current group. This can take several minutes for a large database (with several thousand accounts). An alternative is to use the NIS+ name server to locate these users. This takes only a few seconds. However, NIS+ may not be available at some sites. Users who encounter problems here may wish to modify the get_primary_group_affiliation() function in CCP/MemEdit.cc, or remove the call to it.
Other problems may occur as a result of some calls made with the popen(3S) function. For example, when a printer selection dialog is created, a call to lpstat(1) is made to get a list of printers. The routine that extracts the printer names from the pipe expects the data to be in a certain format. If that format is violated, the printer list will contain garbage. If this kind of problem occurs, the code must be modified to handle the appropriate format.
If DCWA is to be used site-wide, the system administrator should install and run the Collaboration Database Management System (executable DcwaCDMS) on a machine accessible to everyone who will be using DCWA and take the appropriate steps to make sure that inittab will maintain the program. The same goes for the VConfServer.
This section will discuss the architecture of the DCWA system. An understanding of the organization of the software is important to an understanding of the architecture.
Because of the distinctly different kinds of functionality required in a collaborative authoring tool, and because of file system security issues, DCWA has been broken down into 9 executable programs and 16 modules. The purpose of each executable will be briefly described, followed by the purpose of each module.
dcwa (Collaboration Control Panel) - This is the program that gets everything started. It provides each user with the capability of creating new collaborations, editing the membership of existing collaborations, starting/joining a session of an existing collaboration of which he is a member, browsing the membership and other data about all collaborations, and deleting collaborations of which he is the leader. To facilitate these capabilities, dcwa makes requests to the Collaboration Database Management System, which is described next. This program is frequently referred to as CCP throughout this document, but its executable name is dcwa.
DcwaCDMS (Collaboration Database Management System) - This program services all requests made by dcwa. It is a daemon process that should run continuously on some host that is accessible by everyone at a site. Certain information is kept about every collaboration, including its name, group, membership, and working directory. This information is kept in the daemon's application space and in a file currently named DcwaCDMS.tab (to be used when the daemon is restarted). When DcwaCDMS modifies the database in response to a request from dcwa, it rewrites the DcwaCDMS.tab file.
SessionStart - This program is called when the user elects to start/join a session of a collaboration. It first determines if a Collaboration Coordinator for the collaboration is running, and starts up one if not. Then it starts up the LvEditor from which all work in a collaborative effort is done.
CollabCoord (Collaboration Coordinator) - This program does all the coordination between collaborating members. It handles all requests by users to join a session and keeps track of the users who are currently participating. It also controls all access (through lock management) and modifications to the logical view and routes text and graphics data to all users who wish to view the work being done by other users. The main function of this program is to ensure that all users have a consistent view of the document being produced. There is an instance of this program for every active session of a collaboration. It currently runs on the host of the user who initiates the session and terminates when the session is no longer active.
LvEditor - This is the main program from which users do their work. It provides a tree with nodes that will usually correspond to sections in the document. All text and graphics editing, HTML document generation, node search and semantic net operations, and CASE simulation is accomplished through LvEditor. This program communicates frequently with the Collaboration Coordinator and provides users with a node locking mechanism, and provides access to the video conferencing system.
VConf - This program provides users with video conferencing capabilities. It handles all image and voice capturing, compression, and transmission to other users. It also provides an interface through which users can determine who has a VConf program running and make connections to those users.
VConfServer (Video conferencing server) - This program maintains data about all users who are running VConf at a site. It facilitates the connection of users to other users. Eventually, this program will be able to communicate with VConfServers at other sites, allowing users to connect to any other VConf user on the Internet.
VideoView - Until XIL becomes multithread safe, this program receives all video data from VConf and makes it visible. Note that it only displays the video data; VConf still does all the buffering and handles all synchronization.
Dgftoxbm - This program converts graphics images from DGF (DCWA Graphics Format, the format used by DCWA's Drawing Editor) to X11 Bitmap (XBM) format. From XBM, it is a simple matter to convert the image into a variety of formats, but only 2 colors can be supported.
Dgftogif - This program converts DGF drawings to GIF format. This program was written to enable the inclusion of drawings produced in the LvEditor in HTML documents. When the Portable Network Graphics (PNG) format becomes supported by HTML browsers, conversion to GIF will be scrapped altogether.
The DCWA system is logically divided into 3 libraries, 18 component directories and a single directory containing all the binaries. These will now be described.
dcwa/bin - contains all the executable programs and two subdirectories. The help subdirectory contains all the help files; the templates directory contains document templates used by the CASE subsystem.
dcwa/common - contains a variety of non-network functions and definitions used by all of the executables. Among the contents are convenience functions for posting dialogs, providing file access, and a help viewer. The sources in this directory have been compiled into a library called libcommon.a.
dcwa/network - contains the messaging system used by the dcwa, DcwaCDMS, LvEditor, Collaboration Coordinator, and video conferencing programs. It has been compiled into a library called libnetwork.a
dcwa/LogicalView - contains most of the definitions, classes, and functions used when dealing with Logical Views. This stuff is used by LvEditor and Collaboration Coordinator, and has been compiled into the library, libLogicalView.a
dcwa/CASE - contains all the CASE-related source code used by LvEditor.
dcwa/CollabCoord - contains the source for the Collaboration Coordinator.
dcwa/DcwaCDMS - contains the source for the Collaboration Database Management System.
dcwa/DrawingEditor - contains the source for the LvEditor's graphics editor.
dcwa/filters - contains the source for the filters for converting from DGF format to various other formats.
dcwa/gene - contains the source for the mechanism that LvEditor uses to generate HTML documents from the collaboration document.
dcwa/LvEditor - contains the top level source for LvEditor.
dcwa/management - contains the source for the Collaboration Control Panel.
dcwa/semantic - contains the source for handling node search and semantic net generation from LvEditor.
dcwa/SessionStart - contains the source for the SessionStart program.
dcwa/TextEditor - contains the source for LvEditor's text editor.
dcwa/VConf - contains the source for the VConf program.
dcwa/VConfServer - contains the source for the VConfServer program.
dcwa/VideoView - contains the source for the VideoView program.
Although the project was officially completed on August 31, 1996, the project team are still revising and improving the system continuously. The current executables can be downloaded via
Figure 5-2. A Collaboration structure example
Figure 5-3. The Node Attribute Editor
5.1.2 Editing Text and Graphics
5.1.7 Viewing Remote Editions
5.2 The Collaboration Coordinator
5.2.1 Maintaining the Logical View
5.2.2 Controlling Access to Nodes
5.2.3 Routing Edition Updates
Figure 5.4 A typical DCWA session. UserA has locked to nodes, but is only sending updates on one of them. UserB is sending updates on two nodes and receiving updates on another. UserC is receiving updates on two nodes. The CC routes updates to the appropriate location based on routing table.
6.1 Node Search Window
6.2 Search Session
6.3 Search Examples
6.4 Semantic Network
7.1 DCWA and TCP
7.2 Packet classes
struct Collaboration {
string name; // the name of the Collaboration
string group; // the name of the associated UNIX group
string workdir; // the pathname of the working directory
string leader; // username@domain of leader
MemberList members; // a string list of members
...methods for manipulating this struct...
};
write(socket_descriptor, &name, combined_component_string_lengths)
class CollabDataPacket {
size_t name_len; // length of name string
size_t group_len; // length of UNIX group string
size_t workdir_len; // length of working directory string
size_t leader_len; // length of leader string
size_t num_members; // number of members
size_t data_length; // length of string pointed to by data
size_t *members_lengths; // array of member string lengths
char *data; // composite string of all data
public:
CollabDataPacket(Collaboration *collab);
Collaboration* extract_collaboration;
void receive(int socket);
void send(int socket);
...other supporting methods...
};
void CollabDataPacket::send(int socket)
{
iovec iov[3] = { (caddr_t)&name_len, 6*sizeof(size_t),
(caddr_t)members_lengths, sizeof(size_t)*num_members,
data, data_length };
writev(socket, iov, 3);
}
Void CollabDataPacket::receive(int socket)
{
read(socket, (void*)&name_len, 6*sizeof(size_t));
members_lengths = new size_t[num_members];
read(socket, members_lengths, sizeof(size_t)*num_members);
data = new char[data_length+1];
read(socket, data, data_length);
data[data_length] = NULL;
}
7.3 The Message Classes
struct CDMSMessage {
CDMSMessageType type;
timeval time; // timestamp
void *msgdata;
CDMSMessageType receive(int socket);
void send(int socket, CDMSMessageType a, void *packet);
};
void CDMSMessage::send(int socket, CDMSMessageType a, void *packet)
{
type = a;
gettimeofday(&time, NULL);
write(socket, &type, sizeof(CDMSMessageType)+sizeof(timeval));
switch(a) {
case ADD_COLLABORATION:
((CollabDataPacket*)packet)->send(socket);
break;
... handle other message types ...
}
}
CollabDataPacket packet(collab);
CDMSMessage msg;
msg.send(socket, ADD_COLLABORATION, &packet);
CDMSMessageType CDMSMessage::receive(int socket)
{
static CDMSPacketData data;
read(socket, &type,, sizeof(CDMSMessageType)+sizeof(timeval));
switch(type) {
case ADD_COLLABORATION:
data.collab_data_packet.receive(socket);
msgdata = (void*)&data.collab_data_packet;
break;
... handle other message types ...
}
return type;
}
// determine that a message has arrived
switch(msg.receive(socket)) {
case ADD_COLLABORATION:
CollabDataPacket *packet = (CollabDataPacket*)msg->msgdata;
Collaboration *collab = packet->extract_collaboration();
// perform tests and add collab to database upon success
break;
... handle other message types ...
}
Notes
13.1 Organization of the software
13.1.1 The executables
13.1.2 Functional modules
13.2 Software Repository
ftp://ftp.eng.auburn.edu/pub/dcwa/DCWA.tar.Z
[Berson94] Berson, S. and Estrin, G. and Eterovic, Y. and Tou, I.
and Wu, E., Prototyping Synchronous Group Applications,
Computer, IEEE, Vol. 27, No. 5, May, 1994, pp. 48-56.
[Birman 93] Birman, K. P., The Process Group Approach to Reliable
Distributed Computing, Communications of the ACM,
Vol. 36, No. 12, December 1993, pp. 37-53.
[Chang 95] Chang, K., Gong, Y., Dollar, T., Gajiwala, S., Lee, B.,
and Wear, A. W., On Computer Supported Collaborative
Writing Tools for Distributed Environments, Proceedings
1995 ACM Computer Science Conference, pp. 222-229.
[Cooper91] Cooper, D. and Francik, E.and Levine, S. and Rudman, S.E.,
Putting Innovation to Work: Adoption Strategies For
Multimedia Communication Systems, Comm. ACM, Vol. 34,
No. 12, Dec., 1991, pp. 53-63.
[Cuena93] Cuena, J. and Garcia-Serrano, A., Intelligent Computer
Support, in Cooperation among Organizations --- The
Potential of Computer Supported Cooperative Work,
Power, R.J.D. (Ed.), Germany: Springer-Verlag, 1993,
pp. 72-102.
[Diaper93] Diaper, D., Small-Scale Collaborative Writing Using
Electronic Mail, in CSCW in Practice: An
Introduction and Case Studies, Diaper and C. Sanger
(Eds.), Germany: Springer-Verlag, 1993, pp. 72-102
[Dollar97] Dollar, T. W., Ensuring Document Security, User
Coordination, and Multimedia Synchronization in a
Prototype Groupware Suite, Ph.D. Dissertation,
Auburn University, 1997.
[Goldberg92] Goldberg, Y., Safran, M., and Shapiro, E., Active Mail -
A Framework for Implementing Groupware, Proceedings
CSCW '92, ACM Press, pp. 75-83.
[Greenberg91] Greenberg, S., Computer-Supported Cooperative Work
and Groupware, Computer-Supported Cooperative Work and
Groupware, edited by S. Greenberg, Academic Press
Ltd., 1991, pp 1-7.
[Grudin94] Grudin, J., Computer-Supported Cooperative Work: History
and Focus, IEEE Computer, May, 1994, pp. 19-26.
[Haake92] Haake, J. M. and Wilson, B., Supporting Collaborative
Writing of Hyperdocuments in SEPIA, Proc. of the 1992
CSCW Conference, Nov., 1992, pp. 138-146.
[Hennessy90] Hennessy, J.L., and Paterson, D.A. Computer
Architecture: A Quantitative Approach, Morgan Kaufmann
Publishers, Inc. 1990.
Hewitt93] Hewitt, B. and Gilbert, G. N., Groupware Interface, in
CSCW in Practice: An Introduction and Case Studies,
Diaper and C. Sanger (Eds.), Germany: Springer-Verlag,
1993, pp. 31-38.
[Ishii91] Ishii, H. and Miyake, N., Toward an Open Shared Workspace:
Computer and Video Fusion Approach of TeamWorkStation,
Comm. ACM, Vol. 34, No. 12, Dec., 1991, pp. 37- 49.
[Liang94] Liang,, T. and Lai, H. and Chen, N. and Wei, H. and Chen,
M., When Client/Server Isn't Enough: Coordinating Multiple
Distributed Tasks, Computer, IEEE, Vol. 27, No. 5,
May, 1994, pp. 73-79.
[Liberty96] Liberty, Jesse and J. Mark Hord, Teach Yourself ANSI
C++ in 21 Days, pp. 609-621, SAMS Publishing,
Indianapolis, IN, 1996.
[Lockwood94] Lockwood, R., The Groupware Market, Computer Support for
Co-operative Work, edited by K. Spurr, P. Layzell, L.
Jennison, and N. Richards, John Wiley & Sons, Chichester,
1994, pp. 1-18.
[Medina-Mora92] Medina-Mora, R., Winograd, T., Flores, R., and Flores, F.,
The Action Workflow Approach to Workflow Management
Technology, Proceedings CSCW '92, ACM Press,
pp. 281-288.
[Moser96] Moser, L. E., Melliar-Smith, P. M., Agarwal, D. A., Budhia,
R. K., and Lingley-Papadopoulos, C. A., Totem: A
Fault-Tolerant Multicast Group Communication System,
Communications of the ACM, Vol. 39, No. 4, April
1996, pp. 54-63.
[Montes92] Montes, M. and Newman-Wolfe, R. and Webb, M. Implicit
Locking in the Ensemble Concurrent Object-Oriented Graphics
Editor, Proc. of the 1992 CSCW Conference, Nov.,
1992, pp. 265-272.
[Newman-Wolfe92] Newman-Wolfe, R. E., Webb, M. L., and Montes, M., Implicit
Locking in the Ensemble Concurrent Graphics Editor,
Proceedings CSCW '92, ACM Press, pp. 265-272.
[Orr92] Orr, J. N., Graphics and Groupware: Increasing Intimacy
through Broadening Bandwidth, Proceedings of
Groupware'92, Morgan Kaufmann Publishers, 1992, pp. 73-76.
[Palmer93] Palmer, L. G. and Palmer, R. S., DECSPIN: A Networked
Desktop Videoconferencing Application, Digital Technical
Journal, Vol. 5, No. 2, Spring, 1993, pp. 65-76.
[Power93] Power, R. J. D. (Ed.), Cooperation among Organizations ---
The Potential of Computer Supported Cooperative Work,
Germany: Springer-Verlag, 1993.
[Rein93] Rein, G. L. and Ellis, C. A., rIBIS: A Real-Time Group
Hypertext System, Int. Journal of Man-Machine Studies,
Aug., 1993, pp. 339-367.
[Roseman92] Roseman, M. and Greenberg, S., GroupKit A Groupware Toolkit
for Building Real-Time Conferencing Applications,
Proceedings CSCW '92, ACM Press, pp. 43-50.
[Sharples93] Sharples, M., Adding a Little Structure to Collaborative
Writing, in CSCW in Practice: An Introduction and Case
Studies, Diaper and C. Sanger (Eds.), Germany:
Springer-Verlag,, 1993, pp. 51-68.
[Sohlenkamp94] Sohlenkamp, M. and Chwelos, G., Integrating Communication,
Cooperation, and Awareness: The DIVA Virtual Office
Environment, Proceedings CSCW '94 (Oct. 22-26, Chapel
Hill, NC, USA), ACM/SIGCHI/SIGOIS, NY, 1994, pp. 331-343.
[Stefik87] Stefik, M. and Foster, G. and Babrow, D. and Kahn, K. and
Lanning, S. and Suchman, L., Beyond the Chalkboard: Computer
Support for Collaboration and Problem Solving In Meeting,
Communications of the ACM, Vol.30, No.1, Jan., 1987,
pp. 32-47.
[vanRenesse96] van Renesse, R., Birman, K. P., and Maffeis, S., Horus: A
Flexible Group Communication System, Communications of
the ACM, Vol. 39, No. 4, April 1996, pp. 76-83.
[Watabe90] Watabe, K. and Sakada, S. and Maeno, K. and Fukuoka, H. and
Ohomri, T., Distributed Multi-party Desktop Conferencing:
MERMAID, Proc. of the Conference on the Computer Support
Cooperative Work, Los Angeles, CA, 1990.
INCOMPLETE