Yeah exactly - it was all new for us. IIRC the first paper on algorithm wave used was written in 1995.
You can use hashes to make a DAG of edits, like git does. It makes it a lot harder to figure out which operations you're missing when you connect, but you can still transform so long as you know the dependancies of an operation. There's also a trick where you write a 'prune' function (which is sort of an anti-tranform function). That lets you can send around transformed operations and still use them to ingest operations from other clients. I got a proof-of-implementation working, though its pretty slow because I'm doing some dumb things. This generates random operations in a loop at random sites, and randomly pulls operations from site to site. The whole thing stays consistant. https://github.com/josephg/tp2stuff/blob/master/node.coffee#L210-L213 -J On Tue, Jun 11, 2013 at 11:15 AM, Michael MacFadden <michael.macfad...@gmail.com> wrote: > Joseph, > > By nobody had heard of OT, I assume you mean nobody at Google. People had > been creating toy apps based on OT since the mid 90's. Several of them > use a purely P2P model like COT, GOTO, etc. > > As far as hashing, how would that help? > > ~Michael > > On 6/11/13 6:50 PM, "Joseph Gentle" <jose...@gmail.com> wrote: > >>On Mon, Jun 10, 2013 at 1:53 PM, Michael MacFadden >><michael.macfad...@gmail.com> wrote: >>> There are pros and cons to doing OT in a client-server or P2P manner. >>> Googles view was that if you have potentially hundreds or thousands of >>> collaborators, then in a P2P mode you wind up with state vectors, vector >>> clocks, or context vectors that are just to large. Each peer has to >>>track >>> the state of each other client. Operations typically have a context >>> vector attached to them. In this case you have context vectors, and >>>state >>> tables that grow out of hand. Google chose to avoid this by using a >>> client server OT model. >> >>Nobody had heard of OT when wave was conceived - nobody really had the >>expertise to build a scalable system that worked over P2P. It was a >>pragmatic decision rather than some clever design choice. >> >>You're right about vector clocks and so on. How do you feel about >>copying git and hashing operations? >> >>-J > >
