Not a problem. I hadn't even noticed that the e-mail was not going to the list.
I read your blog. I don't know about Google's client implementation, but the FedOne implementation doesn't work as you described it. The "toy" client doesn't perform OT at all. It sends the delta directly to the server without applying it locally. And only applies (composition no transformation) the transformed deltas that are sent from the server. This means that the client won't display the submitted text until the server has transformed and returned it. In the server-to-server case, only the original delta is transmitted. The ProtocolAppliedWaveletDelta message contains the original, un-transformed, delta and hashed version at which it was applied. Host [O1, O2, O3] Remote1 [O1, O2, O3, Oa] Remote2 [O1, O2, O3, Ob] Remote3 [O1, O2, O3, Oc] Assuming order of arrival is Oa, Ob, Oc Host [O1, O2, O3, Oa, Ob', Oc'] Remote1 [O1, O2, O3, Oa, Ob', Oc'] Remote2 [O1, O2, O3, Ob, Oa', Oc'] Remote3 [O1, O2, O3, Oc, Oa', Ob'] On Mon, Nov 30, 2009 at 7:15 PM, Daniel Paull <[email protected]> wrote: > Hello All, > > It appears that I pressed the "reply to author" button rather than > replying to this group this morning. My message and Tad's reply (Tad > - I'm sure you'd be happy to have this published to the group) can be > found below. Apologies for the confusion. > > Tad - operations are executed in different orders on the server and > client (lets forget the federation of servers as this is not what the > OP was asking about). They must be executed in different orders since > the client applies operations before sending them to the server, so > operations concurrently performed by other clients will arrive after > the local operation has been applied. This can even be seen in the > diagram in the Google OT whitepaper - the server and client take > different "OT paths", meaning that the client and server have applied > operations in different orders. > > You may also like to read my blog entry here: > http://www.thinkbottomup.com.au/site/blog/Google_Wave_Operational_Transform_and_Server_Acknowledgments > > As that might help you understand how clients will apply concurrent > operations in different orders. > > > Cheers, > > Dan > > > > From Tad's email: > > You're correct the result would be either "1716" (A first) or "1617" > (B first). I should have remembered the way that works from my > previous tests with wave OT. > > However, Wave doesn't use server ID's in the way you mentioned. All > delta's are sent to the federation host first, before being sent (by > the fed host) to all other participating servers. So, while federation > remote servers also perform OT, they do it in a fixed order as > determined by the federation host. No server ID based ordering is > necessary. > > On Mon, Nov 30, 2009 at 4:58 PM, Daniel Paull <[email protected]> > wrote: >> >> Tad, >> >> I don't think you're right at all! >> >> Clearly to preserve the intention of both users, the resulting >> document must be wither "1617" or "1716" (assuming they delete two >> characters and insert two characters. I had assumed that they just >> deleted and inserted one character, so the result would be "167" or >> "176". But this is a moot point.) >> >> If two operations (O1 and O2) happen concurrently, the they one must >> be transformed to include the effect of the other in order to keep a >> linear history of operations (ie, the state space or history buffer). >> However, whether the decision is to order the operations as [O1, O2'] >> or [O2, O1'], the resulting document state MUST be the same. This is >> the fundamental axiom of OT. Research and understand the TP1 >> constraint for transformation operations. The link I provided in my >> previous post to OT Functions in wikipedia should help you with this. >> >> If the order in which concurrent operations arrive at the server >> affects the document state after those operations have been applied, >> then the OT implementation is very, very broken. >> >> >> Cheers, >> >> Dan > > -- > > 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. > > > -- 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.
