RealTime WebViewers

Last modified by cjd on 2014/05/30 15:15

Realtime WebViewers

When you have 2 or more people who want to work on the same document at the same time, you need a Realtime Collaborative Editor. Realtime Collaborative Editors not only send the changes that you make to the other people who are editing but they also handle conflicts when two people are editing the same words at the same time. For example if I delete a word and you delete the same word, our changes should probably be merged. If you and I both write a word in the same place, the editors should to come to agreement about whose word comes first.

The problem with Realtime Collaborative Editors is they're hard! Google Wave project took 2 years and countless engineers to implement, even Realtime/WebODF, a simple Collaborative Editor with reduced functionality took one developer 2 years!

Why So Difficult?

The reason why Realtime Collaborative Editors are so difficult to get right is because every type of transformation to a document is treated as a different operation. If you write a word and at the same time I make the sentence bold, there needs to be a way to handle the collision between insertion of text and making text bold. What if I make it bold and you make it italic? What about bold and underlined, or italic and underlined, or underlined and text insertion? Every possible combination of changes to a document needs to be accounted for!

And you have to do it twice

If the insane complexity of getting all of this right wasn't enough, traditional designs require it to also be done on both the client and on the server. This is why most realtime editors are written for node.js where the same code can be used on both. Worse, if you have a realtime text editor and you want to add a Realtime Whiteboarding, you need to add the component to the server-side code, making traditional Realtime Collaborative Editors fundamentally incompatible with WebViewers.

A Different Approach

With the new purpose-built ChainPad realtime engine, the server is able to be replaced by a simple message bus and the logic is all moved to the client side allowing new types of Realtime Editors to be installed without modifying server-side code!

This new approach to Realtime Collaboration not only allows for Peer-to-Peer and Zero-Knowlege editors but also will in due time allow Realtime Collaboration to be added to the WebViewer specification.

How ChainPad Works

ChainPad Algorithm is a Realtime Collaborative Editor algorithm based on Nakamoto Blockchains. This implementation is designed to run with a dumb broadcasting server but with minimal effort, the algorithm could be ported to full peer-to-peer. Because the ChainPad server need not be aware of the content which is being edited, different types of editors can exist in harmony on the same system.

Demo Time

This is only a demo so your work will not be saved.
Register/log-in and edit a page normally for full realtime with auto-save.

What About The WYSIWYG?

ChainPad solves the server problem but it still treats everything as a string of text. Wysiwyg and other graphical editors work on structured data, usually HTML. Handling HTML edit conflicts as if they were text conflicts will cause invalid or horrifically incorrect HTML. The solution to this is still in experimental stage but we intend to design a general-purpose HTML patching/transformation algorithm to make all WYSIWYG and basically all in-browser HTML realtime-editable.

Try it out! It's still experimental

Tags:
Created by Administrator on 2014/05/14 17:34

This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 5.4.4 - Documentation