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
