And another update: as at rev 164:4f45c73684df the code is checked into the mercurial repository. initech-corp.com is running the new code. For the next day or two we'll leave acmewave.com running the old code so that you've got an easy test if you suspect the new XMPP code is causing you breakages.
Thanks Anthony On Mon, Feb 22, 2010 at 15:13, Anthony Baxter <[email protected]> wrote: > These changes are now live on wavesandbox.com. Please let us know if > you see anything broken. > > Thanks, > Anthony > > On Mon, Feb 22, 2010 at 11:10, Anthony Baxter <[email protected]> wrote: >> Hi folks, >> >> As a heads up, we'll be pushing a new version of the federation code >> to wavesandbox.com shortly. This new release contains a significant >> refactor which is more robust in how it handles error conditions and >> also generates a richer set of error responses, which we hope will >> make it easier for other wave providers (using FedOne or other >> implementations). The error handling is using standard XMPP error >> stanzas, as documented in IETF RFC 3920. >> >> We'll be updating the federation specification to go into more detail. >> While we expect FedOne-based deployments will continue to operate >> normally after this new release, other implementations may need to be >> modified to gracefully respond to the various error responses >> generated. Please let us know if you see glitches, and we'll keep an >> eye on things from our side. >> >> In addition to the changes to wavesandbox.com, we're working to merge >> this new XMPP code into FedOne, so that the mercurial repository will >> match the new wavesandbox.com release. >> >> In other news, those who were watching the checkins saw a new agent, >> probey. This provides an extremely bare-bones HTTP interface to a wave >> server, allowing you to create, modify, and view waves. It's >> deliberately limited to the purposes it was written for (automated >> end-to-end testing and monitoring of wavesandbox.com), but we hope it >> will be useful for you too, and perhaps even inspire you to look at >> taking the code and extending it further. >> >> Finally, we're thinking about some improvements for the next version >> for the federation protocol - in particular, bundling of signatures as >> an optional part of a submit-request, removing the pubsub envelope on >> post/get signer request/responses and specifying the error messages >> exchanged by federated wave providers. If you have specific >> suggestions about how to improve the server-to-server federation >> protocol, it's a great time to propose them. >> >> Thanks, >> >> Anthony >> >> -- >> Anthony Baxter, [email protected] >> > > > > -- > Anthony Baxter, [email protected] > -- Anthony Baxter, [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.
