On Sun, Dec 12, 2010 at 9:33 PM, 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. > There's still one thing that's fuzzy in the spec concerning submitted deltas and the subsequent delta updates. When a client submits a delta, the way it transforms wavelet updates is different depending on whether or not the update was applied before or after the submitted delta. If the client has no way of knowing when if the submit response will arrive before or after subsequent updates, then it must cache all updates until it gets a submit response. Then it can process cached updates. If it is guaranteed that deltas that where applied after the submitted delta will not be delivered to the client prior to the actual submit response, then the client can use the versionAfterApplicationto distinguish between updates before and after the submitted delta. Consider the case where three clients each submit a delta against wavelet version 5. Let sat that client 2's delta is applied first creating version 6, then client 1's delta is applied creating version 7, and then client 3's delta is applied creating version 8. If client 1 can expect: 1. Update 6 2. Submit response 3. Update 8. then the client need not cache updates. If on the other-hand, client 1 has no guarantee of when the submit response will arrive, then it must cache updates until it knows the submitted deltas versionAfterApplication. I think that the client/server protocol should explicitly state that the server will never deliver wavelet updates that occur after the submitted delta until the submit response has been delivered. This implies that the updates and submit request/response all happen on a single connection. -Tad -- 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.
