Hi Torben, I clearly miss the first lines of your email :) were you state 'no wait' is better...
Is not so complicate to detect your own deltas, just as you said check author is enough, also, as you proposed some kind of token would be need if server does not enforce FIFO model to process incoming Deltas from a client, (for instance opening a new thread for each incoming Delta without any scheduling) Also, a clear optimization here is to have a Delta Aggregation service on the client so you can group a Bunch of independent Deltas generated sequentially after the last known Server wavelet state to Server and apply them in onone shot. Anyway, from my implementation experience, I can tell you this kind of performance optimization could be necessary if maybe one of the participants have a round trip delay > 3-4 seconds to server to receive a submit response from server, and often will depend more on the nature of the collaboration. (However above optimization can have a small drawback, for instance, if you have an implementation where you are Sharing Undo Context, and each Applied Delta is applied on remote clients as a one Undo Unit, as grouping of operations will be managed by 'the number of operations you do' vs. 'delay to server', (as this kind of aggregation can happen during delay to receive an update from server)) m2c jesus On 14 dic, 02:34, Torben Weis <[email protected]> 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 [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<wave-protocol%2bunsubscr...@goog > > legroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/wave-protocol?hl=en. > > -- > --------------------------- > Prof. Torben Weis > Universitaet Duisburg-Essen > [email protected] -- 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.
