On Feb 3, 5:37 am, John Barstow <[email protected]> wrote: > On Wed, Feb 3, 2010 at 4:44 PM, Turner <[email protected]> wrote: > > Hi John, > > > Is that correct? If so, I'm a little confused about how the clients > > deal with this. For example, client A has applied A1, A2 and A3, and > > gets back streamA' from the server (right?). But it can't just apply > > B1-3', can it? I haven't worked it out, but I don't believe that that > > would work. Does client A hold off on "committing" its changes to its > > own content until it gets the up-to-date version from the server > > (whether compressed by the Composer or not)? > > Here's how I explain it; note that I'm working off memory at the > moment so someone might have to correct me. > > At startup, clients A and B get the latest version from the server. > Let's be arbitrary and say we start at v7. So the server and both > clients are synced at v7. > > Key point 1: The "last known version" is how the server knows what > needs to be transformed! It's sent as part of every delta. > > Client A generates some operations. Let's say [A1, A2, A3]. It sends a > delta to the server containing the operations and the last version it > knows about. ([A1,A2,a...@v7) > > Server sees the delta from client A, sees that it's still at v7, so > just commits the delta as v8. It sends back a response that > essentially says (no changes, now at v8). > > Client A has no outstanding edits, so it just bumps the "last known > version" variable internally. > > Client B generates [B1, B2, B3] and sends a delta ([B1, B2, b...@v7). > While waiting for a response, it generates [B4, B5]. > > Key point 2: Any operations generated while waiting for a server > response need to be tracked, because they might get transformed! > > Server sees the delta from client B, and that there is a newer > version. So it takes all the operations committed since v7 and > transforms them. > > [A1, A2, A3] x [B1, B2, B3] = [A1', A2', A3'], [B1', B2', B3']
Ah, ok. So the transformer doesn't transform op streams from different clients so much as it transforms op streams from different versions. Is that it? And the transformer operates pairwise? So, if there's a stream with more ops than the other stream, the unmatched ops go through unchanged, correct? And if there's a disparity of more than one between the version numbers, the transformer will need to be called several times on successive pairs, right? So, for instance, to bump a client whose last known version is v6 to v8, the server would call (v6 x v7) x v8. Do I have that right? In the example above, A1' = A1 X B1, B1' = B1 X A1, and so forth, right? Thank you so much for your great, detailed responses, John--they're helping my understanding immensely. > > The B' operations get saved as v9. The server generates a response > saying ([A1',A2', A3'], now at v9). > > Client B now needs to apply the changes returned by the server, but it > has some pending operations. That means it needs to apply a transform. > > [A1', A2', A3'] x [B4, B5] = [A1", A2", A3"], [B4', B5']. Client B > applies the A" operations and bumps the "last known version" to v9. > The [B4', B5'] can now be sent to the server as a delta ([B4', > B5']...@v9). > > Since v9 is that latest version, the server applies the delta as v10. > The response says (no changes, now at v10). Client B has no more > pending operations, so it just bumps the "last known version" to v10. > > Client A sends an empty delta to ping the server ([...@v8) and gets a > response of ([B1',B2',B3',B4',B5'], now at v10). > > Since Client A has no pending operations, it applies the delta as-is > and bumps the "last known version" to v10. > > We're done, now the server and both clients are synced at v10, even > though all three applied different sets of operations! > > Anyplace you have a sequence of operations bundled up - anywhere I've > used [ ] brackets - you can optionally do a compose to reduce the > length of the sequence. > > I hope that makes sense! Tracing that out was the main thing I did to > get my head around the algorithm. -- 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.
