Hacker News Reader

Comment by collint | Hacker News Reader

I try not spend too much time on semantics at the transformation level. There are already hundreds of cases that must be understood transformed just to handle concurrent operations on an XML document. If you want the transformer to handle semantics I fear you're going to balloon in complexity to the point of deep sadness. ( What do we do if I'm typing a number inside your word? Word inside a number? Delete a number inside a word? What if you word is the name of city? etc. forever )

I think there is a better ROI on making the intent of your collaborators clear, such as with cursor/mouse indicators. If I can see you're editing a number, I can know to steer clear, or at least be ready for the consequences.

View on HN

I've written ShareJS, which performs OT over generic JSON objects.

Getting OT-for-JSON working involved a lot of cases, but it was certainly tractable. The tricky algorithmic code is 440 lines long.

XML would be much more complicated to get right, but certainly possible if you're mad keen on XML.

Did you really need it on the JSON level? It goes over the wire, hence it is essentially just a string.

Yes, you do.

Say you have an object:

{x:1}

Two people try and add a y:2 to the object. If you treat the object as a string, you can end up with:

{y:2,x:1,y:2}

... which is invalid JSON. If you do string-level operations, there's heaps of ways the JSON can end up invalid or just plain wrong. In comparison, using OT if two people apply a "Insert y:2 into the object" operation, the object will be edited correctly at all sites.

Joesph's reply is absolutely correct. I just wanted to add that JSON is a special case of what I noted above: OT is more of a protocol than an algorithm, it takes in operations and performs a transformation on them. It's up to you to decide what those operations are and how to transform them.

The canonical example of a text document with operations consisting of inserting or deleting strings of characters is a little error-prone, but in the context of humans editing text in real time, there's an assumption that they will correct any visible artefacts.

However, when you have structured data created and consumed by algorithms, your tolerance for artefacts goes down to nothing, and you need to choose a different set of operations and carefully design the transformation function.

In between structured data and unstructured text there is also text with semantics. As noted above, you can ignore that and leave it up to humans to fix it, or you can bake some smarts about the text in. There are existing products that treat numbers as a special case, for example. It may not be worth the effort, that's a design choice.

Anyhow, this is a lot of blowhardiness just to say that OT isn't an error-free way to synchonize strings, nor is it just one algorithm, it's a protocol and part of the design process is deciding when and how to go beyond plain text and the obvious transformations on the operations.

Reply on news.ycombinator.com