The descriptions are relatively sketchy and the details given are not hard requirements but meant to get you thinking about possibilities.
Real-Time Jitter Management and Scheduling Support
Traditionally, real-time computing has focussed on embedded applications, developing scheduling algorithms for meeting deadline. Kevin and others in multimedia have looked at real-time issues raised by audio/video conferencing, studying not only scheduling , but also jitter and latency management. Some researchers have also applied these ideas to collaborative virtual environments. Recently, Monica Kum and I looked at the application of jitter management to a demo drawing tool. Popular shared whiteboards meant for wide-area networks (such as the one provided by NetMeeting) do not send incremental input to other users, probably because of the jitter problems. Simulating such a network and simulating RPC calls, Monica found that the performance of incremental sharing can be horrible. She implemented alternative solutions to this problem, and compared them using the simulated network. Her modules are general-purpose in that they are not tailored to a whiteboard, and should be usable for other applications.
At least three related extensions of this work are possible as class projects.
Simultaneous input by multiple users can cause inconsistencies, as these operations are received in different order at the different sites. We can try to prevent such inconsistencies through distributed locking, but that can slow the users down. One approach is to hope that inconsistencies will not arise, and detect and possibly merge them in case they do. Jon Munson developed a general framework for merging Java objects, but it was designed for asynchronous collaboration. Several people have developed mechanisms for real-time merging for text editors. The two directions can be combined in a module that generalizes the real-time merging algorithms by working on Java objects such as Vectors instead of a text buffer.
The Web is perhaps the most effective tool for collaboration currently, but provides direct support only for publishing results to others. There are ways to use a Web browser for collaborative editing, but they require application-specific code. CGI scripts could change a shared database, and users could fill HTML forms for changing this database. Java applets running with the browser could support more synchronous collaboration. Java servlets and enterprise beans can be additionally used to ease the programming of these applications. There is little support, though for integrating the HTML and Java support, besides allowing applets to be embedded as Java tags. Possible projects are:
There has been relatively little work to see how these devices can be used for collaboration. One possibility explored so far is to use Palm Pilots for providing input to a desktop computer whose screen is projected to all users. Using these devices for both input and output and for both synchronous and asynchronous collaboration is intriguing. The challenge here is to see how desktop collaboration systems must be adapted to the small screens and relatively low processing power offered by these machines. Web-based collaboration offers a solution for these machines, since they will all provide some form of Web support. Another direction is to try and write lightweight versions of systems such as Sync that offer as much functionality as possible on these machines. Yet another direction, for connected interaction, is to offload the processing on another machine. For those of you interested in this project, we will get you handheld computers to experiment with during the semester.
Collaborative Software Development
A task we all indulge in that is crying for collaborative applications is collaborative software development. Possible projects:
Collaborative Paper Preparation
Another activity needing help is collaborative document preparation. Several systems have been developed, and based on these designs a system, much like the software development system, can be developed for allowing both synchronous and asynchronous design. As in the software system, the main task will be done using some existing system such as Word or TeX and this system will allow version management, annotations, and design (outlining) support.
Another popular collaborative application, many designs have been proposed, but there is much scope of improvement. For instance, jitter management techniques can be added to provide incremental sharing of drawings. Instead of writing a whitebaord from scratch, an existing whiteboard such as the one used in Sync can be used as the basis. Flexible coupling and awareness techniques are other missing features that can be added to it.
One of the reasons collaborators like to be co-located is that they can be aware of each others activities, knowing when they should interrupt each other, monitoring each others activities, and so on. Several kinds of support for awareness have been proposed such as audio sounds to indicate how close (in a document) a collaborator is to what you are editing, the size of the files they are editing, the diffs between their files and yours, and so on. Based on existing designs, a general component integrating these designs can be developed. Awareness through Web pages would be particularly effective.
Similarly, a generic module for supporting collaborative undo/redo can be developed. See the undo/redo paper in the list of papers linked from my home page.