Hi there, I'm maybe a bit out of date on current C/S implementation, so sorry if II state something wrong here but for what I remember for wave-vs implementation on this...
Theory for Client Side is to cache you local updates sending one by one to server while accept WaveletUpdates coming from Server. Last time I read specifications it was stated you can send only one update to server, (what makes sense for many reasons), and you must cache other local updates until Server send to you a convenient SubmitResponse to notice your delta has been applied, then you can send other one in the queue I don't know how C/S is implemented on WiaB code but on wave-vs Server side.. You really don't need to identify specially your own Delta, as it must not come back to you trough Applied Delta, this is redundant, you already have your delta locally and you know it has been applied and the right location at the time you receive a SubmitResponse from Server as all received updates after this are BEFORE your Delta, and, any subsequent AppliedDelta you receive from Server is AFTER your Delta. As far as I know Server continues processing deltas one-by-one... Knowing this you can apply OT straightforward and update you local document and begin again the process to submit a new delta (new or cached pending to send) Of course, this also implies Client Sending Delta only receive a SubmitResponse for last delta send to Server and not receive his own Delta Transformed using an "AppliedDelta"... Additionally this is redundant transmission as Sender is able to recompose Transformed Delta (if transformed) locally applying OT in the right sequence. Anyway, this is the 'easy' part, the complex part is to apply OT in the right way as you need to keep several versions for each delta that are in involve in the middle of a Server update ,(send, cached and received), to be able to apply the right state when composing document and recovering partial states as you can guarantee real delta order. >From this point there is two strategies to follow on Client side we can discuss but we need first to agree in the above theory. jesus If to here current specifications match I can explain how we deal with updates and OT on client side On Tue, Dec 14, 2010 at 2:34 AM, 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. > > 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. > > Greetings > Torben > > > > > > 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 wave-proto...@googlegroups.com. > > To unsubscribe from this group, send email to > > wave-protocol+unsubscr...@googlegroups.com<wave-protocol%2bunsubscr...@googlegroups.com> > <wave-protocol%2bunsubscr...@googlegroups.com<wave-protocol%252bunsubscr...@googlegroups.com> > > > > . > > For more options, visit this group at > > http://groups.google.com/group/wave-protocol?hl=en. > > > > > > -- > --------------------------- > Prof. Torben Weis > Universitaet Duisburg-Essen > torben.w...@gmail.com >
