Protocol for collaborative tools

Protocol for collaborative tools

Introduction

Our approach is similar to that of the Synchroedit project. Our goal is to create a multiuser realtime editor for abstract documents. A document can be x(ht)ml, SVG drawing, UML diagram… The main difference in our approach is that we develop an intermediate level protocol that deals with objects, not with the DOM Nodes as in Synchroedit (which is specially tailored for text editing using low-level DOM events, thus being impossible to extend it for SVG editing in IE).

The advantage of an intermediate level protocol is that it can be implemented using different techniques: DOM Tree manipulation using Javascript, ActionScript, VML, SVG, etc.

The architecture of the collaborative tools on top of XWiki project consists of three parts:

1.The Request Server ? XWiki integration. This should be a script driven component running on the application server. A user requests an synchronous editing session for a document, either new or in progress. The Request Server locks the file for editing, and sends these requests to the Sync Server. When the editing session is over (there are protocol levelsno users editing the document) the Request Server will be notified by the Sync Server in order to unlock the file.

2.The Sync Server -- This is a Java application that registers the requests from the Request Server, and returns a session reference back to the Request Server, which in turn passes it on to the user in the form of a URL. It is responsible with mediating the synchronous editing between all the users and submitting the document to be saved to the Request Server...

3.The Sync Client -- When the link is selected, Javascript editor for the respective document type is loaded into the user's browser, and a connection is made to the specified Sync Server for the specified session, with the specified username. Depending on the type of file being edited, the client will provide the user with a editor and a chat room to communicate with the other users editing. All the user actions are sent to the Sync Server which then relays the changes to all the users. When the last user leaves the session, the Sync Server submits the final document to the Request Server.

Thus the Sync client consists of a specialized WYSIWYG editor responsible with notifying the Sync server of the user actions and with transforming the DOM tree according to both the user actions and the server messages.

Protocols

There are two protocols which need to be used:

1)Session Protocol: describes the communication of the Sync Server with the application (in our case XWiki)

Application -> Sync Server

Sync Server -> Application

2)Synchronization Protocol (CTP):

Client -> Server

Commands:

UPDATE (transformName) (parameterMap) (objIdArray)

string (transformName) the name of the transformation (scale, fillColor, move, order...)

Map (parameterMap) a map with the specific parameters of the transformation (such (dx='5', dy='10') for a move transformation)

string() (objIdArray) an array with the ids of the objects transformed

Description: Modify existing objects.

CREATE (tempObjId) (objType) (parameterMap)

string (tempObjId) a temporary id of the new object

string (objType) the type of the created object

Map (parameterMap) a map with the specific parameters of the object

Description: Create a new object.

REMOVE (objId)

string (objId) id of the deleted object

Description: Delete an object (can also be a UPDATE(remove,,objId) transformation)

CHAT (msg)

string (msg) the message

Description: Send a chat message

COLOR (color)

string (color) the color assigned to the user's chat messages

Description: Change the color associated to the user in the chat

Concurrency issues

One of the main issues with synchronization is concurrent access to objects. There are more approaches on that:

1)last modification persistent: this approach eliminates many concurrency issues by allowing everybody to change his own copy of the object, however, the last UPDATE is the persistent one. Its advantage over the next two methods is simplicity and effectiveness, though it is possible to loose some changes because of concurrency. To overcome this, we might visually label objects that could be part of concurrency conflicts.

2)object locking at selection: when selecting one object, a lock is to be acquired on the server; should the object be already locked, then selection fails (possibly with a visual mark)

3)object locking at editing: locking doesn't occur at selection, but when the UPDATE message reaches the server. If the lock fails, the modification is dropped (the user should be signaled visually). This request is added to a map (user, objId) for pending requests. When a certain object is to be unlocked, users that have been pending upon it are informed accordingly. (also, signaled visually)

A lock is removed either after a certain amount of time(i.e, 10 seconds) or when the user that has the lock sends a release message (e.g. when selecting another object).

......

Client side editor

Please see the requirement engineering sheet at CoWUseCases.pdf