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 > > > > 2009/11/15 Morgan <[email protected]> > > > > > > > > > > > > > I find this extremely useful thank you. I'm also attempting to start > > > down the road of my own wave server implementation and I think it > > > helps to know what I'm up against. I'm not as far along as you are > > > since I have very little free time at the moment but hopefully some of > > > these things will start to be addressed as I come across them. > > > > > Regarding #4, are you implementing the same algorithm as the FedOne > > > code? I was under the impression that it was supposed to handle > > > conflict situations but perhaps it's not fully addressed yet. I'm an > > > OT newbie so there may be some misconceptions on my part. > > > > > On Nov 14, 8:14 pm, Daniel Danopia <[email protected]> wrote: > > > > Today I set aside a nice chunk of time to get Ruby on Sails > federating > > > > with the sandbox. I intend to write up an article on WaveCompass with > > > > some of my opinions on how it worked out, but this post will have to > > > > do for now. > > > > > > Sails has already come a big way from the first federated wave: > > > > <http://danopia.net/galleries/screenshots/sails/new_fed_to_fedone>. > > > > Seasoned wavers will note the blip ID is a leftover from the single > > > > document FedOne used to use. > > > > > > Sails now gets up to this point: <http://danopia.net/galleries/ > > > > screenshots/wave/123abc_sails>. It also managed relatively large > > > > conversations without crashing, as seen in <http://danopia.net/ > > > > galleries/screenshots/wave/sandbox_fed_1>. It also can communicate > > > > (rather well, without crashing often) with FedOne, and can host a > wave > > > > to more than one servers, as seen in <http://danopia.net/galleries/ > > > > screenshots/wave/sandbox_fedone_sails>. > > > > > > It is still pretty buggy though. Here are some issues I have seen in > > > > how federation/the sandbox works: > > > > > > 1) Annotations seems like guesswork, as far as knowing when something > > > > wants to overwrite an old one, remove it, change the ending, or > simply > > > > not touch it at all and create a new one. Sails currently only > accepts > > > > one annotation per key when they are user annotations, so that there > > > > aren't 1000 cursor and timestamp annotations laying around. > > > > > > 2) Sandbox is way too persistent. I find it bugging Sails about > > > > history requests and delta submissions for waves that boomed > > > > yesterday. > > > > > > 3) Sandbox booms too often without giving me any type of debug info. > > > > At least a little would be nice sometimes. > > > > > > 4) With char-by-char comes collisions. What happens if there's a > > > > collision on a Sails-hosted (or Sandbox-hosted) wave, where two > people > > > > create a delta at exactly the same time? Before federation, the > server > > > > would probably handle this without much thought, but with federation > > > > there's more issues. Should I error the sandbox in return when > there's > > > > a conflict? Should I modify its delta to go onto the new "most > recent" > > > > and send back like that? (The issue there is that I have to re-sign > > > > the delta myself). > > > > > > 5) User information is not federated in any form. Will it ever be > > > > possible for the sandbox to show avatars from users from other > > > > domains? Will I always be using email addresses to identify remote > > > > users in the frontend, such as in the "blinky-bits"? > > > > > > 6) The sandbox will *not* federate waves that it hosts. I can't get > it > > > > to do a single thing to send me a single packet or even connect to my > > > > server. > > > > > > 7) Not that I got here yet, but I see a potential issue in how inline > > > > replies are anchored. The whitepaper for the new document model has a > > > > <reply/> tag with an ID. It then has it point to the <thread> with > > > > inline=true. The thread tag has an ID but the doc said it doesn't do > > > > anything. How are multiple inline replies handled? > > > > > > 8) There's no way to say a wave boomed in the docs. I understand that > > > > there are standard ways to error out IQs in XMPP, but the docs should > > > > at least say the preferred error to respond with. > > > > > > 9) I heard that AppSpot isn't federated and instead has a HTTP/JSON/ > > > > RPC system. How the heck will this be handled in federation? Will > > > > every server have a list of robot servers, and know how to talk to > > > > them? Or still appspot soon be federated to handle this? > > > > > > I managed to get Sails to share DB configs with my Rails app, so > > > > persistance is now pretty high up on my list of things to do. > > > > > > I hope that this isn't viewed as an attack on Wave but rather as a > > > > list of things that Wave could use to become more awesome. As always, > > > > I can be contacted at [email protected] (wave or email) and on > > > > freenode IRC in #googlewaveservers. > > > > -- > > --------------------------- > > 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 -~----------~----~----~----~------~----~------~--~---
