Types of Collaboration: Object based

This implementation of real time collaboration seems to offer the best balance between performance, usability and developer needs. This is why we chose it for the current XTWIP implementation of collaboration.

The object based approach follows these 4 simple rules:

• The data model of the collaborative application can be represented as an XML. Of course, the application can pull data from Twitter, Flickr or Facebook, but by data model we mean the data the application stores.

• Whenever the application changes something, it just notifies the XTWIP client-side SDK that “something has changed”. The SDK automatically detects what has changed and send the difference over to the XTWIP server and to the other application instances.

• In order to better avoid conflicts, the XML may have atomic tags or non-atomic tags. An atomic tag has an unique ID attribute and it may contain either atomic or non-atomic tags. A non-atomic tag does not have a unique ID and it may only contain other non-atomic tags. The XTWIP SDK provides the unique IDs and it guarantees they are unique across all application instances. You can think of atomic tag as components which the developer considers important enough to separate and non-atomic tags as properties of those components. See the example below to get a better idea.

<!– The document is an important tag, so it gets a unique ID –>

<document id=”7″>

<!– The same goes for the button –>

<button id=”9″>

<!– The attributes of the button however, are not that important from a collaborative stand-point  –>

<label text=”Collaborative Button” color=”6600FF”>

<background src=”xtwip_logo.jpg>

<background color=”222222″>

<link url=”http://www.xtwip.com”>

</button>
[...]

</document>

• When two application instances (actually, two users) change the same atomic tag at the same time, the last change has priority over the first. Of course, a merging of the content will be attempted – failing that, the last change will remain. The distinction between atomic and non-atomic tags comes in very handy here, because it tells the merging algorithm how it should try to match tags.

This (apparently) simple protocol provides application developers with a simple gateway to collaboration. No longer do they have to write server-side code or write their own custom code for diffing and merging differences. The XTWIP SDK together with the XTWIP Collaboration Service provide that for just a few lines of code. All developers need to do is read the tutorial, drop a few lines of code into their application and they can redeploy their application as a collaboration experience.

Let’s look at the advantages:

1. Very easy to deploy. There is not specific server-side logic and developers can just embed their application and the XTWIP SDK takes care of the rest (connecting to server, handshaking, getting data, posting differences and so on)
2. Very easy to implement. All you need to add to your application is: listening for when outside changes appear (so you know when to redraw), notifying the SDK of when something has changed, serializing your data model (XML serialization is already built in the SDK) and adding a connect statement on application load. That’s it !
3. Fast execution, low CPU cost. Unlike Operational Transforms methods, object based diffing is significantly faster.
4. Guaranteed consistency. This means that all application instances will rapidly converge to the same instance of the data model, no matter how many changes are being performed.

There are only two disadvantages:

Number one. If two users happen to modify the exact same atomic object at the same time (within 300 ms of each other, on average), the XTWIP SDK will automatically merge the two changes. When merging fails, the last change performed will implicitly have priority.  Merging means a further analysis of what has changed (attributes, child tags) and putting it all together. Merging usually fails when the two users change exactly the same attributes and no automatic conclusion can be drawn as to who’s right.

In our experience, however, this type of fine-grained micro-conflict between versions is very rare. When it does happen, the users notice it right away. They tend to immediately react and choose a final state for the change they wanted.

Number two. Whole pieces of the data model are serialized and send across the network, so if your application deals a lot with raster image editing, object-based collaboration is not the best idea (at least, not by itself).

If you want to try this type of real time collaboration with your own application, create a Developer Account on XTWIP and there you’ll find everything you need:

• A short tutorial on how to get started
• The client side SDK
• A full documentation on the protocol
• A full description with examples on how to manage (create, delete, request access) to multiple collaborative instances (workspaces)