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