Come on, it's broken. Maybe I can find a contrived example to illustrate:
1) There are two clients that both have the the same, empty wave open. 2) Client1 generates O1 and sends it to the server. 3) Client2 generates OA and sends it to the server. O1 and OA happen to be identical. 4) Client1 generates O2 and caches it, waiting for the server to acknowledge O1 before sending O2. 5) The server decides to apply the two concurrent operations in the order OA then O1. So, it applies OA after transforming it (the transformation happens to be a no-op at this stage) and broadcasts OA to all clients. 6) Client1 receives OA, compares it to its unacknowledged operation, O1. They are the same, so Client1 incorrectly assumes that the server has acknowledged O1. 7) Client1 sends OA to the server and we all go to hell in a hand basket as the server is not expecting Client1 to send operations at this time. It may just so happen that two clients will arrive at the same state in the above scenario (assuming that the server doesn't kill off the misbehaving client). However, I would expect divergence when more than two clients are involved. Maybe that would be worth proving, but I think it's sufficient to show that Client1 can send operations at the wrong time when following your approach. Cheers, Dan On Jan 20, 7:41 pm, Brett Morgan <[email protected]> wrote: > On Thu, Jan 21, 2010 at 12:37 AM, Daniel Paull <[email protected]> wrote: > > > > The client that failed cannot detect that it failed, because the other > > > delta looks exactly the same. Thus, in the end "Hello" will be inserted > > only > > > once. > > > Bingo! It's clearly a broken approach. Perhaps that's why its not > > talked about in Google's OT whitepaper? > > No it's not a clearly broken approach, mainly because it isn't broken. The > trick here is that the edits are transformed, and thus are different. The > server and both clients will wind up with the document "HelloHello". I know > this because my LCA2010 webapp deals with this exact issue, and it handles > it without breaking a sweat. > > > > but I see no solution for this when relying on delta comparisons. > > > Yep, there is no correct solution using this approach. > > > > I agree that this is an academic corner case, > > > Egad! This is not an "academic corner case". That's like calling > > deadlock detection and transaction rollback an academic corner case > > for a RDBMS. It is so important that the OT functions be proven to be > > correct in order to build the simplest OT system that can be relied > > upon. Reliability is more than a mere academic concern. > > 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]<wave-protocol%2bunsubscr...@goog > > legroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/wave-protocol?hl=en. > > -- > Brett Morganhttp://domesticmouse.livejournal.com/
-- 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.
