Hi Brett, thanks for the suggestion. However, it seems to me that this approach is not completely correct.
Imagine two clients which are sending a delta against the same server version. The delta says to insert "Hello" at some position in a blip. The correct outcome is "HelloHello" being inserted. Now one client fails to submit its delta, the other one succeeds. 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. I agree that this is an academic corner case, but I see no solution for this when relying on delta comparisons. Greetings Torben 2010/1/19 Brett Morgan <[email protected]> > If you are transforming your docops, you can compare the docops coming back > down for equality. You are doing client side transformations, right? > > org.waveprotocol.wave.model.operation.OpComparators is the FedOne code for > comparing equality of ops. Which, after a whole bunch of edge case checking > turns into the following comparison: > > DocOpUtil.toConciseString(a).equals(DocOpUtil.toConciseString(b)) > > In short, comparing docops for equality is easy, as long as you keep > transforming your docops... > > On Wed, Jan 20, 2010 at 9:42 AM, Torben Weis <[email protected]>wrote: > >> Hi James, >> >> How about when the client connects to the server again it does a history >>> check against the known good deltas it has sent out. If the last delta >>> it sent out isn't in the history, then it hasn't been received. >>> >> >> The problem is that this is impossible. How should QWaveClient recognize a >> delta as >> being its own? The server has perhaps transformed the delta, i.e. simple >> delta comparison >> is not possible and looking at version numbers does not help either. >> >> Greetings >> Torben >> >> >>> >>> -- >>> >>> James Purser >>> http://wavingtheshiny.collaborynth.com.au >>> Wave Addresses: >>> [email protected] (wave.google.com) >>> [email protected] (wavesandbox.com) >>> [email protected] (collaborynth.com.au FedOne Server) >>> Skype: purserj1977 >>> GTalk: [email protected] >>> >>> >>> -- >>> 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. >>> >>> >>> >>> >> >> >> -- >> --------------------------- >> Prof. Torben Weis >> Universitaet Duisburg-Essen >> [email protected] >> >> -- >> 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]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- --------------------------- Prof. Torben Weis Universitaet Duisburg-Essen [email protected]--
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.
