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 at 
> http://groups.google.com/group/wave-protocol?hl=en.
>
>



-- 
Brett Morgan http://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.

Reply via email to