I think I read that. I guess that the sandbox will be ok as long as it gets an ACK back for the packet. I'll try doing that later, as my dad decided it's a good day to dig out hte dirt floor in our garage and prep it for concrete.
On Nov 15, 1:35 pm, Tad Glines <[email protected]> wrote: > You really need to re-read this > paper:http://www.waveprotocol.org/whitepapers/operational-transform > If your server is hosting a wavelet and the current version is 25 and > the sandbox sends you a delta (with two operations) with a of version > 23, then your server MUST: > 1. Transform the delta against versions 24 and 25, > 2. Apply the delta, > 3. Send submit-response to sandbox (operations applied=2, version=27) > 4. Broadcast a ProtocolAppliedWaveletDelta to all participant's severs > (including the sandbox). The ProtocolAppliedWaveletDelta contains the > original signed delta. > > If your server has properly implemented the OT code, then there will > be no collisions. In cases where two remotes send a update attribute > operation modifying the same attribute, then last to arrive wins. > > You will want to look at the > "org.waveprotocol.wave.model.document.operation.algorithm.Transformer" > class to see how transformations are performed. > > On Sun, Nov 15, 2009 at 8:46 AM, Daniel Danopia <[email protected]> wrote: > > > The issue that I see is when I host waves and the sandbox sends a > > submission for an older version. The sandbox seems very picky about > > submissions and might not recognize the delta as being the one it > > submitted if it's signed by someone else (me) with a different > > applied_to version. Plus it'd get the other delta with the same > > applied_to as the one it sent to me, which would probably confuse it > > further. > > > On Nov 15, 10:50 am, Torben Weis <[email protected]> wrote: > >> In fact the trick is to apply a delta to a newer version if there was a > >> conflict. > > >> The server hosting the wavelet is always right. Thus, if a delta generated > >> by your "ruby on sails" client conflicts with a delta sent by the > >> wavelet-hosting server, you must transform (!!) your delta thus that it can > >> be applied to a newer version. Just sending out the same delta (without > >> transformation) and applying it to a higher version number will sometimes > >> work and sometimes not. > > >> In addition, you must have at most one pending delta submit at a time. Then > >> you must wait until this delta is applied by > >> the server hosting the wavelet. Now you can submit the next delta. And so > >> on. This simplifies the OT process inside the server > >> and is a difference between the Jupiter system and Wave. > > >> However, I wonder how to handle signing after transformation. Transforming > >> a > >> delta will invalidate its signature ... > > >> Torben > > >> 2009/11/15 Daniel Danopia <[email protected]> > > >> > I con resolve a delta by changing it to be applied at a newer version, > >> > but then I'd hae to take over signing it with my own signature. It > >> > also seems like FedOne and the like only accepts one delta per > >> > applied_to. If there is somewherei in the docs saying how to handle > >> > these conflicts with the Wave protocol, then I'd be glad to read over > >> > it. I just missed it the first time. > > >> > On Nov 15, 10:08 am, Torben Weis <[email protected]> wrote: > >> > > What you are calling "conflict" handling is indeed solved by applying > >> > > OT. > >> > If > >> > > you refuse or cancel some deltas because of "conflicts" then you did > >> > > something wrong, i.e. you have no OT in place. While developing > >> > QWaveClient > >> > > this turned out to be the most complex part of it all. > > >> > > I highly recommend reading the Jupiter paper, especially the part about > >> > the > >> > > "xform" function. > > >> > > However, there are conflicts if some client does not play according to > >> > > the rule. > >> > > For example if one delta wants to remove a StartElement at the same > >> > > position where a "conflicting" > >> > > delta wants to remove an EndElement then something went wrong -> > >> > > conflict > >> > > -> wave explodes -> reload. > > >> > > Greetings > >> > > Torben > >> > > --------------------------- > >> > > Prof. Torben Weis > >> > > Universitaet Duisburg-Essen > >> > > [email protected] > > >> -- > >> --------------------------- > >> 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 -~----------~----~----~----~------~----~------~--~---
