How is your approach different from http://neil.fraser.name/writing/sync/ ? You said you aren't doing any diffs - so are you just creating a patch per user action (like typing the character "a" is actually represented as a patch for insertion of a at position 0?). I looked at using differential synchronization at some point, but it has even higher latency/way more memory usage than OT approaches (the server needs to have a full copy of the document per client). You can't constantly be diffing and sending patches using the synch-diff approach - rather you have synchronization cycles that happen every few seconds.
Yes, I represented everything as patches. The native file format was going to just be a series of patches, so that in the single-user case I could implement the "never have to hit save" functionality just by appending to the patch stream. (An active save might have reset the patch stream to just be a straight dump of the current document.)
In my more evil moments I considered specifying the save file as an XML document that deliberately left off the final close tag. Mu-hu-ha-ha-ha!
Pretty much the same as that doc, yes, though I never saw it. (I did see and was inspired by the Darcs patch theory doc I linked.) My plan was for people to "share" documents, so a server that had a full copy of the document was not a problem, it did by definition. For that matter, in the Google Wave model, I'd rather run my own Wave server so having a full copy of the document there isn't a problem either. I, personally, actively don't want my cloud to have the canonical version of the document.
"You can't constantly be diffing and sending patches using the synch-diff approach - rather you have synchronization cycles that happen every few seconds."
Why not? Assuming just a handful of users (not hundreds), and given that patches have a certain flexibility about when they get applied, why not just send things as they occur? (Within the topologies shown, that is, not just everyone sending to anybody as they feel like it. You could probably get by with full P2P without too much work, but having the central server simplifies things a lot and I don't think you lose much. I was never planning on 100 people "in" the same document.) Clients should probably chunk things up a bit during periods of rapid typing. (I was planning on going to raw sockets if I needed to; most higher level protocols would have indeed choked this from what I saw.)
Anyway, it's pretty theoretical now. Wave is probably good enough and this wasn't even the focus of my project, just an incidental sideline to what I really wanted.
The thing about not constantly being able to send patches - I'll need to think about it again, but I thought I came up with a reason for why it didn't work in a general case.
And I didn't just mean saving a copy of the document on the server - you need to do this for most collab. algos. The differential synchronization algorithm requires saving a copy of the document _per client_ on the server.
Otherwise - sounds cool - you should definitely try to implement this and see how it goes.
