I also removed the numOpsApplied field from submitDeltaResponse. I remember discussing this with someone at the summit. The client can only handle the case where the opsApplied == the number of ops sent. The field existed to support transforming of operations away to nothing, but this is a rare case and transforming to a no-op works fine.
A. On 13 December 2010 16:33, Alex North <[email protected]> wrote: > 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.
