Thank you Dan, just the kind of information I was looking for. cheers,
Chiang On Apr 14, 12:43 am, Daniel Paull <[email protected]> wrote: > Hi Chiang, > > I posted a couple of entries on my blog a while back on server > acknowledgement and TP2 that you can find here: > > http://www.thinkbottomup.com.au/site/taxonomy/term/45 > > They might help answer some of your questions. > > Cheers, > > Dan > > On Apr 13, 5:38 pm, chiang <[email protected]> wrote: > > > 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.
