I've updated the document in response to these comments and further thought, including some notes on participant removal.
https://sites.google.com/a/waveprotocol.org/wave-protocol/protocol/design-proposals/clientserver-protocol 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. > Done. > > 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. > I added that as a potential extension. We never had a need for it in Google Wave though. If the client is fetching historical data it usually wants as compressed a form as possible, which is not the full delta history. > 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? > This was a bit dodgy and on further reflection I've removed explicit wavelet creation. Instead, a wavelet is created by submitting the first delta to it (this is how Google Wave works too, and plays much better with federation). > > -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.
