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 -~----------~----~----~----~------~----~------~--~---
