On Mon, Jul 28, 2008 at 11:18 PM, Jack Moffitt <[EMAIL PROTECTED]> wrote:
> > 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. The server can use a sax parser, they do work on streams; there is no magic required. Resending multiple stanzas isn't really any different than in regular syntax either, because when the server acks you a rid you resend as expected; essentially you break up your <body> payload into sub 2K chunks and make them a single text node in the <body> (the schema in 124 does not reflect that IIRC). > > > 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? Yea, I would have implemented what I mentioned above except Openfire doesn't currently support it anyway =\. It treats everything as valid payload markup from the moment it comes off the wire. If it did though, it would be trivial. > > > 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. I'm with neither. But, their use case as I see it is to bridge web-based presence and messaging to an XMPP network and that's what 124 does. > > > 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. They gain nothing, it's true. I just love everything being built on 'open' standards (though as psa called my mistake on, bayeux is not). > > > > 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. > > > It does predate it by a couple years. I was mistaken about bayeux being open, but really what I mean is something that xep implementors can reuse. Best, Harlan
