> Hmmm, interesting. Would you mind summing up the known gotchas for those of > us who didn't make it to the summit?
Well my first thought in looking at it was "great, but so much for long stanzas since GET urls in IE are restircted to 2k". But reading the spec closer it looks like this was thought of. Unfortunately it says you need begin body and end body on each request, even if the request is a partial stanza. So this means that the BOSH server needs some kind of magic to know when a stanza ends. Also, if a stanza is sent over multiple ASS requests, what do you do when you need to resend? It's clear that incremening rid here was the wrong choice, as this breaks completely. For instance, if your window is 5 and you have a 14k stanza to send which fails, you can not resend it. Whoops. There are other issues as well. According to Blaine Cook using ASS over a pipelined connection results in bad caching behavior in some browsers. This mean that only the first response has any useful data, and future responses are carbon copies. Asking the developers present at the summit who implemented ASS, it's clear everyone implemented the trivial case of Everything Fits In A Single GET. So as far as I know, no one has actually implemented the spec completely anyway. Note that just because ASS will be removed from BOSH doesn't mean you can't use it in its simplified form. Just know that this is not a generally useful way to do XMPP cross domain from javascript. Avatars, private xml storage, and many other things will not work reliably in all browsers because of the GET url length limits. > I can agree that it maybe was an uncalled for late addition, but really I > had no problem implementing it (not to say I couldn't have assumed things > that weren't written). I only had to change only my write and > onWriteResponse methods for it to work; otherwise the code is identical to > regular syntax. And you handle resent requests of arbitrary length? > If you're going to be cleaning house, is there any chance of removing HTTP > error codes or saying they MUST coincide with actual BOSH 'terminate' error > responses being sent? This hasn't been a major problem for me, but I scratch > my head as to why HTTP codes are in there if not for legacy reasons. I'll look into this. >> I think the real solution is to implement your cross domain support >> with window.name tunneling from a hidden iframe. I'll work up an >> example of this soon. > > I'm trying not to be an apologist for script syntax, as long as we have some > form of x-domain possible I'm happy =] IMO that is essential for this to be > a viable standard to build a SaaS social platform on (my interest ;). > Already though, Facebook and most likely Meebo will roll their own mechanism > based on bayeux-like protocols to communicate with XMPP servers which I > consider to be a sign that the open standard isn't friendly to their use > cases. Are you at Meebo or Facebook? For starters, it is not clear that facebook is even using Jabber in the backend. I was under the impression that their XMPP support would be a translation layer to whatever they have in the back. From their public announcement it certainly seemed like they had rolled their own proprietary chat protocol with Erlang. As for Meebo, I don't see what they would gain by switching to bayeux, unless they already have extensive bayeux infrastructure. If they do, it's not a big deal if their servers are limited to their clients. As long as they federate, the network is still open. > Speaking of open standards based approaches, is there any interest in > perhaps even creating another standard that relies on Bayeux rather than > specifying a custom COMET protocol like XEP-0124 does? Doesn't XEP 124 predate Bayeux? I don't think there is going to be much objection to a Bayeux based XEP. jack.
