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