Going to a peer-to-peer OT system (synonymous with vector clocks and satisfying TP2) does not imply chaos. Different nodes in the network can adopt roles and, say, be authoritative. I see the current Wave topology as one possible configuration of a peer-to-peer OT system.
Let me recap - the upside is that document ownership *can* be distributed, but the upside is also that *ownership* is logical concept layered on top of OT. Hang on, there's no downside there. > In short, I'm not completely sold that we can implement a vector clock > based OT for federation and have it stable in the face of both bugs > and future feature requests. That depend on who you refer to as "we"... The first hurdle is satisfying TP2. Cheers, Dan On Jan 31, 4:53 pm, Brett Morgan <[email protected]> wrote: > Dan, > > Swapping over to a vector clock based OT for federation has both > upsides and downsides. The upside is that the document ownership is > distributed. The downside is that the document ownership is > distributed. > > If everyone can agree up front what the valid modifications to a > document are, including such fun and games as access control lists and > the like, and everyone implements the same rules, exactly, then maybe > it will work. One misstep and we have failure to converge nightmares > that require debugging across multiple hosts. > > On the flip side, by having exactly one master, then all the rules > around acceptable edits only have to live in one place, and can be > changed both on a document by document basis, and over time, enabling > system growth and change. The cost of this adaptability to change is > that if a host disappears, the conversations that host was hosting are > now toast. > > In short, I'm not completely sold that we can implement a vector clock > based OT for federation and have it stable in the face of both bugs > and future feature requests. > > brett > > > > > > On Sun, Jan 31, 2010 at 7:15 PM, Daniel Paull <[email protected]> wrote: > > It's more than just an option - it's the only clear path forward. > > Hopefully Dan Peterson and crew understand that. > > > Cheers, > > > Dan > > > On Jan 31, 12:55 pm, Brett Morgan <[email protected]> wrote: > >> Dan, > > >> An option is to use a variant of OT that uses a vector clock instead > >> of the current single master OT. > > >> The fun thing would be that using a vector clock OT would even help > >> out in the construction of fault tolerant Wave hosts, instead of > >> having single points of failure inside the data center. > > >> brett > > >> On Sat, Jan 30, 2010 at 12:45 AM, Dan Peterson <[email protected]> > >> wrote: > >> > Agreed. This is an area I've been thinking about lately -- the electing a > >> > new master scheme is appealing, but then what do you do when the original > >> > master returns to the rest of the network (e.g. the uplink that was > >> > severed > >> > is restored, then there'd be 2 servers that think they are master)? > >> > As an alternative scenario, I suppose the wave client UI could encourage > >> > a > >> > "fork" of the wave conversation -- copying the latest version of the > >> > contents into a new wavelet on the non-dead wave provider. Of course, > >> > forks > >> > are effectively duplicate content, so not so ideal. > >> > -Dan > > >> > On Sat, Jan 30, 2010 at 12:36 AM, Torben Weis <[email protected]> > >> > wrote: > > >> >> Hi, > >> >> I fear it is not as easy as assigning it to missing FedOne features. > >> >> If the master wave server breaks you need some other server to take > >> >> over. But the domain name of the broken server is encoded in the wavelet > >> >> URIs which are encoded (i.e. signed and hashed) inside the deltas. > >> >> Thus, you > >> >> cannot simply replace the wave server without taking care of the > >> >> cryptographic problems. > >> >> Even if this is dealt with, how do you efficiently vote on a new master > >> >> server? It must not happen that at any time there is doubt about the > >> >> master > >> >> server (i.e. several clients deem different servers to be the master). > >> >> Wave's OT cannot handle such a scenario. There are peer-to-peer OT > >> >> concepts > >> >> which can deal with it, but wave does not currently. > >> >> I think this is a really interesting research question, but the solution > >> >> will not be all too easy. > >> >> This being said, even normal federation is complex enough :-) > >> >> Cheers > >> >> Torben > >> >> 2010/1/29 Mickaël Rémond <[email protected]> > > >> >>> Hello, > > >> >>> Le 29 janv. 2010 à 13:17, chiang a écrit : > > >> >>> > Hi all, > > >> >>> > This could already have been a known deficiency in the federation > >> >>> > architecture, but I would like to enquire if it is by design that we > >> >>> > have authoritative or master wave servers for a particular wave? As > >> >>> > I've just found out that if the Fedone wave server (which hosts a > >> >>> > master copy of my initiating wave) goes down or losses all the waves, > >> >>> > the Fedone wave server does not recover the wave from wavesandbox, > >> >>> > which also has a copy of the wave. I initially thought wave servers > >> >>> > federation is supposed to be scalable, and resilient... > > >> >>> Fedone is an example implementation, not a production ready wave > >> >>> server. > >> >>> For example, it still miss the storage engine, is not clustered etc. > >> >>> So this limitation is not by design but simply a not-yet-implemented > >> >>> feature. > > >> >>> Having an authoritative server for every wave seems a good and needed > >> >>> approach for the Wave protocol itself. > > >> >>> -- > >> >>> Mickaël Rémond > >> >>> http://www.process-one.net/ > > >> >>> -- > >> >>> You received this message because you are subscribed to the Google > >> >>> Groups > >> >>> "Wave Protocol" group. > >> >>> To post to this group, send email to [email protected]. > >> >>> To unsubscribe from this group, send email to > >> >>> [email protected]. > >> >>> For more options, visit this group at > >> >>>http://groups.google.com/group/wave-protocol?hl=en. > > >> >> -- > >> >> You received this message because you are subscribed to the Google > >> >> Groups > >> >> "Wave Protocol" group. > >> >> To post to this group, send email to [email protected]. > >> >> To unsubscribe from this group, send email to > >> >> [email protected]. > >> >> For more options, visit this group at > >> >>http://groups.google.com/group/wave-protocol?hl=en. > > >> > -- > >> > You received this message because you are subscribed to the Google Groups > >> > "Wave Protocol" group. > >> > To post to this group, send email to [email protected]. > >> > To unsubscribe from this group, send email to > >> > [email protected]. > >> > For more options, visit this group at > >> >http://groups.google.com/group/wave-protocol?hl=en. > > >> -- > >> Brett Morganhttp://domesticmouse.livejournal.com/ > > > -- > > You received this message because you are subscribed to the Google Groups > > "Wave Protocol" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/wave-protocol?hl=en. > > -- > Brett Morganhttp://domesticmouse.livejournal.com/ -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
