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%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/wave-protocol?hl=en.
>
>
>
>


-- 
Brett Morgan http://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.

Reply via email to