My bad - I had assumed that I'd ranted enough for TP2 to be part of
the vernacular here. Transformation Properties (TP) are broken down
well at Wikipedia:
http://en.wikipedia.org/wiki/Operational_transformation#Transformation_properties
Basically, satisfying TP1 means that two sites can exchange
operations, transform and apply them in any order and still converge.
Satisfying TP2 means that three sites can do the same. Interestingly,
it is sufficient to satisfy TP2 to achieve convergence between any
number of sites. I'm sure we could dig up a proof of that from the
literature somewhere...
Do you mean you're "just a programmer" or "*just* a
programmer" (emphasis on "just")? Sorry, you made me laugh, reminding
me of Microsoft's "It just works!" slogan, which I read as "It *just*
work", if you get my drift.
On Jan 31, 9:47 pm, Brett Morgan <[email protected]> wrote:
> Dan,
>
> Break it down for me dude, remember I'm just a programmer. TP2 means?
>
>
>
>
>
> On Sun, Jan 31, 2010 at 9:03 PM, Daniel Paull <[email protected]> wrote:
> > 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
> > 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.
