Hi John, Thank you first of all for the detail explanations. Your explanations did help me confirm my understandings. Think I had some misunderstandings between TP1 and TP2 properties, e.g. on the number of sites exchanging operations, and when do we get two different document states.
Think I'm a lot clearer now, but allow me think out loud and see if these are correct: 1) There are two types of application acknowledgements, one between client and server, and another in the form of commit-notice, which is used when a server "agrees" that the changes should be persisted (presumably the master server will decide when to start propagating the commit-notice), even though the changes have already been applied. 2) Operations are exchanged between only two sites - client and server, or server (slave) and server (master). TP2 on the other hand allows all peers to exchange operations with one another and the final state of the document will still converge. cheers, Chiang On Apr 13, 5:20 am, John Barstow <[email protected]> wrote: > On Thu, Apr 8, 2010 at 8:45 PM, chiang <[email protected]> wrote: > > > The reason I'm seeking clarification is if an operation can be applied > > at the FedOne server without requiring acknowledgement from the master > > wavesandbox, then operations can be applied in different orders, and > > potentially from more than 3 sites. But this does not sound right also > > as I think I have been told that this cannot be done with current > > Google Wave's OT implementation. Or am I missing something huge?! > > You are missing something important. > The while point of the OT algorithm is that any number of sites can > apply the operations in different orders and still end up in the same > final state. > > So things look like this: > > Server M (the master server) has a list of operations it knows about > [a,b,c,d,e,f] > Server A has a list of operations it knows about [a,b,c,d,e] > Client A knows about [a,b,c,d] and has new operations [g,h] > Client B knows about [a,b,c,d,e,f] and has new operations[k,l] > > Client A sends [g,h] to Server A. > Server A runs the OT algorithm, applies the resulting [g', h'] and > returns [e'] to Client A. > Server A sends [g', h'] to Server M. > Server M runs the OT algorithm, applies the resulting [g", h"] and > returns [f'] to Server A. > Client B sends [k, l] to Server M. > Server M runs the OT algorithm, applies the resulting [k', l'] and > returns [g3, h3] to Client B. > > Server M sends [k', l'] to Server A. Server A has no outstanding > operations so just applies them directly. > Server A sends [f', k', l'] to Client A. > > At the end of this exchange, all 4 participants have converged on the > same state, but they followed a different set of operations. > > Server M = [a, b, c, d, e, f, g", h", k', l'] > Server A = [a, b, c, d, e, g', h', f', k', l'] > Client A = [a, b, c, d, g, h, e', f', k', l'] > Client B = [a, b, c, d, e, f, k, l, g3, h3] > > Having the client wait for an acknowledgment is really a way of > simplifying the algorithm. I find it helpful to think of a version > control system merging between branches - if you allow branches to > diverge too much, merging can become really difficult. But if you > rebase (or merge from the parent branch back to the child branch) > periodically it greatly simplifies things. Applying the server > response before sending more operations is like rebasing before > pushing another set of commits. > > So a real client (like the Web interface) actually acts quite a lot > like a server; it maintains a list of operations it knows about and > runs the OT algorithm when the server tells it about new operations. > However the FedOne client is pretty pitiful; it's more like hacking > directly on the server list of operations, so it obscures much of what > is actually going on. This is potentially where the misunderstanding > creeps in for many people, because they look at the code and think it > represents what an actual client should be doing instead of seeing it > as the hacking tool it actually is. -- 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.
