Introducing CEDA - a platform for collaboration

Today I am pleased to announce the first in a series of white papers that talk about CEDA. What is CEDA? Well, that's exactly what the first paper is about! The abstract of the Introducing CEDA white paper is reproduced below:

CEDA is a high performance database technology that uses Operational Transformation (OT) to support replication and synchronisation for collaborative data entry performed by multiple users. CEDA is an ideal platform for Computer Supported Collaborative Work (CSCW), allowing multiple users to edit that same data concurrently. Users can collaborate in a interactive, realtime manner or work offline and control when changes are propagated to/from other users.

CEDA provides an application development platform for building applications that support collaborative work. Application developers can easily build multiuser applications based on CEDA that are as responsive as single user applications while attaining benefits of realtime interactive collaboration and sophisticated version control. The platform allows for branching and merging of the entire database, supporting manual check-ins, check-outs, updates, tagging and so forth in a similar manner to source code repository systems like ClearCase and Subversion.

The OT algorithms employed by CEDA are extraordinarily efficient, allowing users to work off line for long periods of time and then quickly synchronise with other users.

This paper provides an introduction to CEDA and some of the platforms features.

Think Bottom Up staff have been involved in the research and development of CEDA for the last 12 years or so, though the original research by David Barrett-Lennard goes back further than that. We are very excited about CEDA and the potential of the technology. The collaborative features of CEDA are achieved through the use of Operational Transformation - an area of ongoing research that has gained a lot of press lately thanks to Google Wave.

Comments

This Whitepaper is interesting. I've found the sections on OT quite useful to understand Google Wave (and potentially the problems that have not been solved yet for that system).

Could you please elaborate on "This one example doesn’t convey the complexity of the problem and the subtle issues that have led to numerous erroneous solutions in the literature." Can you provide the erroneous solutions that you are aware of?

There us also a minor spelling mistake, "There are 6 distinct paths that can be take[n]"

Thanks
Benjamin

Thanks for the feedback.

I can't remember where the TP2 puzzles first appeared in the literature. It could be one of the papers by Rui Li, Du Li. It's been 5 years since I read those papers.

I recall one example where there are 3 sites that initially all agree that the shared text document contains a single character 'x'. Concurrently one site inserts '1' just before the 'x', another site inserts '2' just after the 'x' and a third site deletes the 'x'. Evidently after merging the result should be '12' not '21'. However on the cube there is a face where the 'x' has been deleted so the insertion of the '1' and the '2' coincide. The approach of using site identifiers to resolve the tie will get it wrong half the time. I haven't studied the Google Wave approach enough to be sure of this, but I presume that if the server happens to receive the delete then the insertions from the three clients in a particular order then it may impose the "wrong" solution of '21' for all sites.

I'm not suggesting that the Google Wave approach has a deep seated problem. Clearly it will converge and some people may see the TP2 puzzles as mostly of academic interest. However in my mind, there is the significant disadvantage in the way it involves a form of centralisation (because of the waiting on ACKs) and therefore increases latency and will be more fragile than a true peer-peer system (that takes the high road and satisfies TP2). More importantly I cannot see how it will properly support branching and merging in the sense of a revision control system.

David