> > 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.
... 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. That's fuzzy because the proposal gives no such guarantee and a client may not rely on ordering between the wavelet channel and submit delta responses. This is based on the existing implementation. If WIAB happens to order them consistently then that is by chance (an artifact of websocket?) rather than design. A client doesn't need to cache all received updates, only those that arrive after a gap in the contiguous delta version sequence. The WaveletDeltaChannelImpl class in WIAB handles this ordering. Updates are not unnecessarily delayed in practise as the submit response usually does reach the client before the next update. As you note, adding an ordering requirement would restrict the transport to be over a single connection that could provide such ordering (so you couldn't use a universally compatible hanging GET / HTTP POST combination without adding virtual channel overhead that essentially leads to message caching). A possible alternative would be to ignore the submit response and insert a message into the wavelet stream representing the client's own delta, perhaps a WaveletUpdate with no delta. However since the submit request must get some kind of response anyway (for errors) it seems most efficient to include the application metadata in this response, directly associated with the request, than insert another message into the update stream and ignore successful responses. The equality comparison mechanism that Torben mentions is implemented and works too. It's currently engaged only when connections bounce and the client misses submit response messages, as the equality test can be expensive. Essentially the server filters a client's own deltas as a bandwidth-optimising service to the client. In this client/server protocol, reaching users' browsers across widely varying networks, we are quite keen to minimize bandwidth consumption. That's the motivation to drop a client's own deltas, avoid a placeholder message, and also why we have worked to avoid adding something like a unique tag to each delta. We're open to convincing otherwise, but the caching is not an issue in practise. A. On 14 December 2010 13:25, Tad Glines <tad.gli...@gmail.com> wrote: > On Mon, Dec 13, 2010 at 5:34 PM, Torben Weis <torben.w...@gmail.com>wrote: > >> Hi Tad, >> >> this problem was on my mind for a long time. >> Caching updates is not the ideal solution for interactivity and >> collaboration, because updates are unnecessarily delayed. >> >> What a client really needs is a way to detect its own delta when receiving >> it as a wavelet update. >> >> Soren told me how to do this (in theory). Imagine a client has locally >> applied delta D1 and submitted it, however, there is no submit response yet. >> Now it is receiving several wavelet updates: U1, U2, ... Un >> The client transform the delta pair (U1,D1) yielding U1' and D2 and >> applies U1'. >> Then it transforms (U2, D2) yielding U2' and D3 and it applies U2'. >> ... >> >> If one of these deltas U1, ..., Un is in fact the delta D1 after the >> server has transformed it then it must hold that there is some U_i for which >> U_i is equal to D_i. Thus, the client must compare deltas before >> transforming them. If they are equal it has found its own delta. I have not >> implemented this, but it sounded reasonable to me somehow. >> > > When I implemented my own client-side OT stack, I verified that the server > send the submit response before sending updates that where applied after the > submitted delta. This made implementing the client-side OT easier. > > I think the current WiaB server also produces the same behavior. However, > it's not explicitly documented anywhere. > > >> Nevertheless, I once proposed to include a token in each delta such that a >> client can more easily detect its own delta by comparing the author field >> and the token of the delta. Much easier, faster (with respect to CPU time) >> and less error prone. >> > > I've considered the same thing. The server can can easily filter tokens so > that only the client that submitted the delta gest the token in the > response, so there would be no need to compare authors. > > -Tad > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to wave-proto...@googlegroups.com. > To unsubscribe from this group, send email to > wave-protocol+unsubscr...@googlegroups.com<wave-protocol%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. >
