Re: a global delta ordering. We considered this for a while as a simplification to aid some client, but ultimately rejected it. The core reason we decided against it is that it severely limits scalability (in our system, anyway) to require global coordination between many wave servers to agree on a clock/sequence. It depends on the scope of the sequence, but it pretty much forces everything that knows about the sequence to be homed on the same machine. We tried to design a protocol that would not constrain the implementation in that way (not that we necessarily succeeded).
We built all our clients to not rely on cross-wavelet ordering, though a weak form can be gained from timestamps. However, it's still something we could consider again. I hope at the summit we'll be able to talk a bit more about our lessons from scaling Google Wave - it's a bit difficult to communicate everything over email. A. On 26 October 2010 11:42, Tad Glines <[email protected]> wrote: > Yes, participant removal does complicate things. I had to deal with it in a > bunch of places when I was implementing changes for my last project. > > There was one change to the protocol I had to make that I'd like to discuss > at some point. When dealing with a thick client that has a lot of waves > state stored locally and the need to operate disconnected for long periods > of time, there's a need to sync with the server quickly. Having the client > open or make history requests for ALL the waves doesn't scale well. Also if > the client is using wave for things other than conversations it may become > important to be able to order deltas global and not just within a wavelet. > to that end I had to add a global sequence number to the deltas.In this case > it was global with the server. The client could then ask for all deltas that > occurred after sequence number X. This plus a threading change in the server > to ensure deterministic ordering of deltas sent to other connected clients, > allows reliable cross wavelet references (i.e. the referenced item would > always arrive before the reference). > > Any thoughts. > > -Tad > > > On Mon, Oct 25, 2010 at 5:10 PM, Alex North <[email protected]> wrote: > >> Thanks for these great questions, Tad, and apologies for the slow >> response. I lost focus on this amongst a pile of refactorings necessary >> before I could make a real start. >> >> I intend to respond to your questions in detail and update the proposal >> soon. I will just point out though that the remove participant mechanism >> (losing all access) was just a stop-gap, so that we could implement a simple >> version of the protocol and then iterate to address tricky problems like >> that. We have experience from implementing participant removal in Google >> Wave and it turned out to be even more complex than you might think. >> >> Cheers, >> Alex >> >> On 16 October 2010 01:13, Tad Glines <[email protected]> wrote: >> >>> I'd like to see the semantics for participant removal more explicitly >>> documented. In places it's implied that the user looses all access to a >>> wavelet once removed from the participant list, where as in other places >>> it's implied that the user retains access to the wavelet history up to the >>> delta where the participant is removed. It seems pointless to remove all >>> access to the wavelet since the user has already seen (and may have cached) >>> the previous contents. So it seems more reasonable that the participant >>> retains access to all deltas up to and including the delta where the >>> participant is removed. If the participant is removed, added then removed >>> again. the participant should retain access to all deltas up to and >>> including the last delta in which the participant is removed. >>> >>> Having implemented my own client side OT I can say that the logic will >>> more complicated if the delta associated with a client submit is completely >>> omitted. it's easier to match against a version than it is to identify the >>> gap between deltas. Perhaps we could make the delta in WaveletUpdate >>> optional and omit it for deltas that correspond to the clients submit. >>> However, omitting the delta is only valid if the delta stream and submit can >>> be associated with the same client instance by the server. This is simple in >>> the case where the client connects to the server with a single WebSocket, >>> but is more difficult if the client sends the submit via a separate >>> communication channel from the delta stream. >>> >>> If the channelId found in SubmitDeltaRequest is intended as a means to >>> associate a submit with a delta stream then it should be made optional or >>> the description needs to be modified so that it states that the delta >>> channel must be opened before a submit can be made. >>> >>> If we add an optional endVersion to the OpenWaveletChannelRequest, then >>> it can serve as an open-ended subscription or as a closed-ended history >>> request. >>> >>> What would the server return in the version zero snapshot? It's a little >>> hard to tell from the description whether or not the server would be >>> creating the root conversation or if it would only be including metadata. >>> I'm assuming that the only reason you have the wavelet creation service >>> seperated from the delta submit service is so that the server can include >>> initial metadata in the wave/wavelet. If so, what metadata would the server >>> be including? >>> >>> -Tad >>> >>> On Thu, Oct 14, 2010 at 4:23 PM, Alex North <[email protected]> wrote: >>> >>>> Hi all, >>>> >>>> The Google Wave client/server protocol is rather complex and we had >>>> trouble documenting it well. It was never fully implemented in FedOne (now >>>> WIAB). We've recently developed a design for a new, simpler protocol which >>>> I'd like to share with you here. >>>> >>>> >>>> https://sites.google.com/a/waveprotocol.org/wave-protocol/protocol/design-proposals/clientserver-protocol >>>> >>>> Questions and feedback are most welcome. In particular please let me >>>> know if the documentation is unclear. I intend to implement this protocol >>>> in >>>> Wave in a Box over the coming week or so. >>>> >>>> Cheers, >>>> Alex >>>> >>>> -- >>>> 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]<wave-protocol%[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]<wave-protocol%[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]<wave-protocol%[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]<wave-protocol%[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.
