Introduction
As has been discussed in class, in today's society it is highly unlikely that a single person has the capacity to complete a large project by themselves. People need to collaborate with one another in order to accomplish large goals. Especially in the realm of software development, when working on a large project, different tasks and modules will be assigned to different developers or development teams. These individual teams need to further break the problem down, form a design and begin implementation of the problem.
Example: Implementing 32-bit Timers
Drawing an example from personal experience, in the MANTIS research group a team of four developers were trying to implement efficient 32-bit timers on an 8-bit microcontroller with only 16-bit hardware timers. In a methodology similar to Extreme Programming, the team sat around the projected display of a single computer, with one member of the team operating the computer at a time. Lines of code would slowly pour out after much discussion. While this methodology was successful, several drawbacks were noted in this approach:
There was a lot of code to write, and despite having a team of four developers, only one section of the problem was ever being worked on at a time.
Some of the code was very simple, and did not need participation of the entire team.
Some of the code was very complex, and certainly needed the participation of the entire team.
What was really needed in approaching this difficult undertaking was a way for the developers to collaboratively work on the same problem across different machines in real time. If this were possible, one developer could work on the simple code while the others tackle the more complex sections. As opposed to traditional development methods, where each facet of the team would check in their changes to a central code repository, if the developers had a way to see each other's individual changes and comment on them in real-time, the process would be more efficient. They could check one another's changes as they occur, and go through additional design as the code is being written, instead of waiting for one another to check-in individual changes, and possibly having to change their own code to reflect these changes.
One way of enabling this real-time interaction between developers is with a collaborative editing tool. With such a tool, each developer would connect to a central server, and as they work on changes to the code, all of the other developer's displays are updated with the changes in real time. This would enable each developer to have a perfect snapshot of the code as it is being worked on, and would support Extreme Programming practices without requiring a single developer to be operating the computer.
Real-Time Collaborative Systems
When dealing with software collaborative systems, there are two general classes of systems: those which are asynchronous and those which are synchronous. Asynchronous systems include email, chat programs, software version control, and other similar systems in which users post messages of some sort, and the other users of the system are able to respond to those messages whenever is convenient. Synchronous systems are somewhat more difficult to find, but online games and network management via SNMP are good examples. In these systems, each user of the system is able to contribute and receive updates from other users in real-time, as the specific events occur. These systems are much more involved on the individual user level, and require a greater level of interaction from each user. Real-time collaborative systems fall into the synchronous category.
Intention Preservation and Consistency
Two major problems with real-time collaborative tools are intention preservation and consistency[1]. Intention preservation is the idea of making sure that the input a user performs is accurately reflected in the environment. Consistency is the idea that each connected client has an identical and accurate copy of the workspace. Much of the research performed in the real-time collaboration realm is focusing on how to properly maintain the intentions and consistency across distributed clients.
Currently Available Tools
Currently the only other real-time collaborative editing tool found was SubEthaEdit[5]. It is developed only for the Apple platform, and the developers have explicitly stated they have no intention of ever porting it to other platforms. Some other products, such as several office suites from Microsoft and OpenOffice, offer an asynchronous form of collaboration, in which changes are not actually deleted from a file, but are instead crossed out, allowing changes to be tracked.
Colledit: A Simple Real-Time Collaborative Editor
The scope of this project was such that a fully-functional programming text editor was not endeavored. Instead, the design was narrowed in scope to include a simple text editor, along with a separate chatting area in which users could communicate with those currently editing the document.
Colledit is a typical client/server application, in which one of the clients (the one which began the editing session) is also a server. Each connected client spawns a new thread in the server, and opens a TCP socket for communications with the server. Any editing commands are send to the server, verified for consistency, and passed along to any connected clients.
In order to facilitate ease of use on the networking side, Zeroconf[6] support was integrated. Zeroconf uses the DNS protocol to broadcast available network services on a subnet. When a user creates a new editing server, this service is published to the local subnet using Zeroconf. Any other clients on the subnet are notified of this new service, allowing users to connect to one another without knowing details like which IP or port they are connecting to.
The network protocol is relatively simple. A number of predefined events control communication. These events are hello, insert, delete and chat. The hello event notifies other users a new client has connected, and sends any initial text to the newly connected client. Insert and delete are the events supporting inserting or deleting text from the document, respectively. The insert event also includes the color associated with the user performing the insertion. Chat events are similar but more simple than the insert events, also including the user name of the user who wrote the chat message. The event system can be expanded straightforwardly, by adding a new event structure and the associated event marshalling/unmarshalling code. The following diagram illustrates the flow of network events through the system:
Driving the visual display is the text editing widget of the GTK+ GUI toolkit[7]. GTK+ is a portable GUI toolkit, supporting the Linux, Unix, Windows and Apple platforms. As the user performs editing or chatting actions, GTK+ catches these actions, and through special signal handlers, the appropriate network action is performed. A separate thread in each client also listens over the TCP connection, and any incoming events are processed and the appropriate action is passed on to GTK+.
Screen Shots
The prototype is connected to Zeroconf and awaiting a server to broadcast its address.
A server has broadcasted its presence, the server list is updated with the new server.
In another program instance, the user has clicked on the available server, and is presented with the current file being edited. The text is being updated in real time, as either user adds to or deletes from the text area. Each user chooses a color, which is used for the background of the text they type. The chat output area allows users in the same editing session a simple way to communicate and make comments on each other's work or ask questions about their editing decisions.
Need for Collaborative Toolkits
One of the biggest drawbacks to the GUI toolkit chosen, and for that matter the other available toolkits and editors examined, is that they were simply not designed to have multiple input locations. The fundamental limitation is that they only support a single cursor at any time. In an ideal collaborative editor, each user would know where each other is currently editing. The tool developed only supports a single cursor, and as the other users modify the text, it simply appears. In addition to this problem, it would be valuable to have notification of where and what the other users are doing, before displaying the actual input[3]. For example, in the currently implemented tool, if a document is more than one page and one user is viewing the bottom of the document, and another user edits the top part of the document, the first user has no way of knowing changes are being made without scrolling to the top of the document. Also, because of the limited support for collaboration techniques in the toolkit itself, it is guaranteed not to scale very well.
The ideal solution would be to build a GUI toolkit with built-in support for real-time collaboration. In such a toolkit, there would not be restrictions on the number of cursors, or the number of mouse pointers. The toolkit would include a networking backend to support real-time collaboration. Any time a user moved the mouse, or interacted in some other fashion, the other users of the system would be able to see those modifications as they occur. All this would happen behind the scenes, and any application build with this toolkit would automatically make use of these features. This is in stark contrast to the tool which was developed here, in which only a limited number of collaborative events are possible, and each has to be specifically and individually coded to the specific event.
Other Applications for Real-Time Collaborative Systems
In addition to supporting Extreme Programming practices, real-time collaborative editing has other uses. Imagine taking notes in a class with such a tool. If several students in the class were using such a tool, they could collectively take notes on the lecture. If one student missed a portion of what was being presented, chances are another one of the collaborative note takers did get the information, and could fill in the collective notes with it. It also offers a way for members of a distance education class to interact with each other and the teacher, if they are able to view the lectures at the time they are being given.
Conclusion
Although Colledit is rather limited in scale, it is a working implementation of a real-time collaborative editor. The undertaking has shown that current GUI toolkits are somewhat lacking in support for this kind of behavior, and research into how the GUI toolkits can better support real-time collaboration would be interesting. It will also be interesting to see how real-time collaborative techniques will be integrated into other systems, especially commercial products. With SubEthaEdit being several years old now, it is curious that there are not other products with similar offerings.
References
[1]Chris Joslin, Tom Molet, Nadia Magnenat-Thalmann.”Advanced Real-Time Collaboration Over the Internet”. Proceedings of the ACM Symposium on Virtual Reality Software and Technology. pp. 25-32. ACM Press, New York, NY, 2000.
[2]Carl Gutwin, Saul Greenberg. “The Effects of Workspace Awareness Support on the Usability of Real-Time Distributed Groupware”. ACM Transactions on Computer-Human Interaction. Volume 6, Issue 3, pp. 243-281. ACM Press, New York, NY, 1999.
[3]Haifeng Shen, Chengzheng Sun. “Flexible Notification for Collaborative Systems”. Proceedings of the 2002 ACM Conference on Computer Supported Cooperative Work. pp.77-86. ACM Press, New York, NY, 2002.
[4]James Begole, Mary Beth Rosson, Clifford A. Shaffer. “Flexible Collaboration Transparency: Supporting Worker Independence in Replicated Application-Sharing Systems.” ACM Transactions of Computer-Human Interaction. Volume 6, Issue 3, pp.95-132. ACM Press, New York, NY, 1999.
[5]SubEthaEdit, http://www.codingmonkeys.de/subethaedit
[6] Zeroconf, http://www.zeroconf.org
[7] GTK+, The Gimp Toolkit, http://www.gtk.org