undefined

points

[-]

Early versions of google docs didn't even implement OT correctly. There were various cases where if two people bolded and unbolded text in a certain order, while connecting and disconnecting their wifi, the documents would go out of sync. You'd end up looking at different documents, even after everything reconnected.

I (obviously) care a lot about fixing these sort of bugs. But its important to remember that in many applications, it matters a lot less than people think.

by anematode5 hours ago|

prev|

[-]

Of course. But typical, live collaborative software doesn't need to be (and shouldn't be) decentralized. In such software it's annoying to not be able to (even speculatively) acquire unique access to an object. I'd be very surprised if Google Docs used CRDTs now.

by josephg2 hours ago|

parent|

[-]

Part time CRDT researcher here. I think CRDTs would work great for google docs. Google docs has a problem where if too many people open the document at the same time, it needs to lock the document. I assume this is because the document is "owned" by a single computer. Or they use DB-transactional ordering on edits.

If I implemented google docs today, I'd use a CRDT between all the servers. This would let you have multi-master server scaling, and everything on the server side would be lock-free.

Between the server and the client, CRDTs would be fine. With eg-walker, you can just send the current document state to the user with no history (until its actually needed). In eg-walker, you can merge any remote change so long as you have history going back to a common fork point. If merges happen and the client is missing history, just have them fetch the server for historical data.

Alternately, you can bridge from a CRDT to OT for the client/server comms. The client side code is a bit simpler that way, but clients may need server affinity - which would complicate your server setup.