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