Sounds like if servers, clustered or not, can make sure that waves initiated from their domain are always available then everything will be okay. Does that mean that all wave providers, including home set up ones, need to be given strict "guidelines" to set their servers up to some standard before they can be allowed to federate? As I can see the detrimental effects dodgy master wave servers will have on waves contributed by multiple parties. And this is far from just a not-yet implemented feature don't you think?
Chiang On Jan 29, 2:01 pm, Mickaël Rémond <[email protected]> wrote: > Hello Dan, > > Electing a new master on a federation of internet services does not sounds a > idea (at least extremely complex). > Several component can see at the same time that a service is down and elect > themselves master on a given content, which can thus be distributed several > times. > Many other problems can occurs, especially if you consider the internet link > as not reliable. > > That's why I was thinking that the original question was more: "How to make > content persistent on Fedone to avoid loosing waves" than actually how can we > build a fully robust loosely coupled and distributed data and manipulation > system. > Relying on each server building a reliable cluster deployment seems to be > enough for me. > > What could be a nice goal however is to allow read only access to wave that > cannot currently be accessed, but that sounds conceptually easier. > > -- > Mickaël Rémond > http://www.process-one.net > > Le 29 janv. 2010 à 14:45, Dan Peterson a écrit : > > > > > 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 > > athttp://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 > > athttp://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 > > athttp://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.
