SynchroEdit Overview

From SynchroEdit

Revision as of 09:21, 27 October 2007; WikiAdm (Talk | contribs)
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Jump to: navigation, search

SynchroEdit Overview

SynchroEdit is a browser-based multiuser editor. It allows multiple users to share a single X(HT)ML or text document, edit the document the same time, and synchronize changes so that all users have the same version.

It consists of three parts:

  1. The Request Server -- This is the Perl or PHP script on a web server (such as Apache) that the user first connects to. The user can request an X(HT)ML or text file to be synchronously edited, or to join a synchronous edit session already in progress. The Request Server locks the file for editing, and sends these requests to the Sync Server.
  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.
  3. The Sync Client -- When the link is selected, Javascript code is loaded into the user's browser, and a connection is made to the specificed 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 WYSIWYG editor or a plain-text editor (which is essentially the WYSIWYG editor with the styling features disabled; user-coloring is still enabled). The Sync Server then mediates the synchronous editing between all the users. When the last user leaves the session, the Sync Server submits the final document to the Request Server, indicating that the document is to be unlocked again.

More details:

SynchroEdit takes advantage of W3C's Document Object Model (DOM). It is written entirely in JavaScript (the Sync Client) and Java (the Sync Server). Communication between the client and server is currently "bridged" using a set of Perl-scripts.

The Sync Client ensures that user modifications do not interfere with each other by keeping track of where each user is located in the DOM tree, by node. User changes to the document are tracked using event-handlers on the DOM mutation events (as defined here) -- namely DOMNodeInserted, DOMNodeRemoved, DOMCharacterDataModified and DOMAttrModified.

When data is appended to the DOM tree, unaffected nodes remain as they are, which allows users to safely continue editing, even if other users are modifying large chunks of text elsewhere, and even if there is lag in updates.

Every user's edits are marked by "author-spanning". Every user has the ability to change their user color and all edits performed by that user will be reflected in that color.

When a session is initiated, the server parses the X(HT)ML document to be edited into an internal DOM Document object. Whenever a user connects to the server, the document's current state is dispatched to that user as raw XHTML, which is then parsed by the browser into a document.

Via the SedInstance implementation's getNodeIdentifiedAs() and getNodeIdentifierFor() functions, each Sync Client and Sync Server relate which node is being modified using element anchors, sibling-anchor-reference, and child-reference, such as "br_5.1" or "br_5|1".

Using the internal DOM function getElementById(), and using the Node.childNodes feature, the correct node can be located in a mostly relative fashion, providing an environment more or less failsafe against synchronization-issues, except where users are editing the same portion of the document. At the point of writing, this is handled by locking a node when a user edits it. Ideas such as DocumentStateSequence exist, but remain unimplemented.

The Sync Client implementation adheres to the inherent browser DOM functionality in styling as well as editing of the document, with only a few minor tweaks -- tweaks mostly due to bugs in the browser, but also some for optimization's sake. This means that as the browser's internal features are updated and improved, the client will inherit the improvements which relate to the implementation.

Users can at any time request that the Sync Server save the document. The Sync Server will then export the document to the Request Server, which in turn stores it to the appropriate system.

Several examples of SynchroEdit implementations exist at this point. To name a few:

At the point of writing, there is also talks about making a TWiki plugin for SynchroEdit (link to that topic).