Links
Course Documents
     Register
     Main Page
     Assignments
     Contact Information
     Course Announcement
     Schedule and Syllabus
     Course Participants
     Discussion Forum
     Swiki Chat
     Lecture Material
     Independent Research
     Projects
     Questionnaires
     Previous Course
Swiki Features:
  View this Page
  Edit this Page
  Printer Friendly View
  Lock this Page
  References to this Page
  Uploads to this Page
  History of this Page
  Top of the Swiki
  Recent Changes
  Search the Swiki
  Help Guide
Related Links:
     Atlas Program
     Center for LifeLong Learning and Design
     Computer Science Department
     Institute of Cognitive Science
     College of Architecture and Planning
     University of Colorado at Boulder
Background Investigation

Using the Apple Macintosh system of a friend, I was able to directly explore some of the features of SubEthaEdit. It turns out the experience was close to what was described and what I expected, and I did not get any additional ideas from actually using the software.

I then proceeded to investigate various options for the editing component. I looked at the source of several Open Source editors, such as emacs, nedit, jedit, and Eclipse. Although a collaborative editing component would be possible in any of these editors, the problem with these projects is they have to much code to be able to understand and modify it within the timeframe of this project. An especially promising alternative was found in the Scintilla project, which is an Open Source code editing component with many language bindings. The included SciTE editor serves largely as a reference for the editing component library. This is an attractive option, but is still sufficiently complicated that it may be out of scope, depending on other factors described below.

Prototype Design

In the course of evaluating different editor options, I decided it would be a good idea to just start on a prototype to see if some of the things I wanted to do were technically feasible. One thing I wanted the collaborative editor to support was the Zeroconf protocol, enabling hassle-free network configuration. So, the prototype began life as some code to test the howl Zeroconf library. Service discovery was very simple with the howl library, and within little time the prototype implemented Zeroconf support.

The next piece I began work on was the network protocol. Despite what ended up being used for the editing component, the network protocol had to be devised and should largely be the same regardless of the specifics of the editing component. The network protocol consists of a number of events, each of which has a similar header. The header is examined for the event type, which was originally 'hello', announcing a new connection, 'insert', which supported inserting new text into the editing component and 'delete', which supported deleting text from the editing component. It is relatively easy to add new events to this, supporting chat will surely require new events.

With some of the network protocol defined, I was ready to start on the client/server code which would communicate to each other using the events. This is where the Zeroconf configuration comes into play. Normally, when using network software, the client must specify the address of the server, as in DNS hostnames such as www.google.com. Zeroconf allows servers to broadcast their services to the local subnet, and allows clients to easily listen for those service broadcasts. The address of the server is contained in these service broadcasts, so the client can get this information without the user knowing the server's actual address. So, after the client is aware of the collaborative editing server through Zeroconf, it connects to the server, which manages a list of all connected clients and the events which pass between them. A thread is spawned for every client connection, so the server should be scalable. When a new client connects, it sends the 'hello' event, which the server forwards to all other clients. During the editing process, the server sends any necessary editing messages to each client. When a client disconnects, the server removes it from the list and only sends messages to the other connected clients.

With the client and server networking code started and sending events to each other, I needed to start providing a way to display information to the user. Even though I was not completely decided on what to do for the editing component, I needed to start on something, so I decided to proceed using the GTK+ widget set, which I was fimiliar with. This toolkit provides a text editing widgets, which does not provide typical code editing functionality, but I know it well so I was able to get things up and running quickly, and have the intention of replacing some of it with a proper code editing component. I set up a basic connection GUI, listing all available servers using Zeroconf, and an option to start a local server. When the user clicks on a server, the client connects to the server, providing a new window with the current file being edited. When the user clicks on Start Server, a new window comes up with a text editing portion, and a TCP socket is opening to listen for incoming connections. Chat elements were added to the GUI but are not functional at this time.

Screen Shots

Uploaded Image: colledit-server-disconnedted.png

The prototype is connected to Zeroconf and awaiting a server to broadcast its address.

Uploaded Image: colledit-server-connected.png

A server has broadcasted its presence, the server list is updated with the new server.

Uploaded Image: colledit-chatwindow.png

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.

The Work Ahead

In order to support differentiation of individual user contributions, the 'insert' event needs to be extended with user-specific information, so the editor can assign a color to each user, and display any text edited by that user in the user's specific color.

A chat component should be added (with relative ease) to enable editing participants direct communication with one another without having to register or use specific chatting software, or having to resort to connecting to yet another server.

View this PageEdit this PagePrinter Friendly ViewLock this PageReferences to this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide