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