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'] 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.
