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]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
