> > > The main gotcha for the alternative script syntax is that some browsers > limit the length of HTTP URIs (IE limits it to 2K). The solution in XEP-0124 > is weird (stretch the stanza across multiple <body/> GETs), not well > specified, and agreed to be problematic among those at the summit. We had > consensus to move that part of XEP-0124 to a historical spec.
Ah yea, I remember that one. I didn't implement that part because Openfire doesn't support it at the moment anyway; it treats it as valid markup from the moment it comes off the wire. > > > 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. >> >> 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. >> > > Right, they are there only for legacy support. Perhaps they belong > somewhere else now, or we can remove them entirely. > > I think the real solution is to implement your cross domain support >> with window.name <http://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. >> > > And what are their use cases? And why aren't they participating here? Their uses cases as I see them boil down to bridging web-based chat and presence to an XMPP network; I can't say why they're not participating here. That's my use case though and 124 seemed the way to go, and that's why I am here =]. Granted making money by building a silo aren't on my agenda. > > > 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? >> > > I'm not sure what you mean by that. > > 1. BOSH predates Bayeaux by at least 2 years (XEP-0124 advanced to Draft in > March 2005). I'm not insinuating any mistakes, and was debating CMA on that one :) What I am trying to say is that without ASS to overcome same-origin, I think something needs to take its place; be it the iframe tunnel that Jack mentioned or another XEP. Personally I lean against the idea of adding web browser specific stuff to 124 because it really seems like a general purpose standard to me, and has been implemented in Python and Ruby already. Just in the spirit of reusing things, I thought I would throw out the idea of using Bayeux (more as an example than anything I'm fancy to) to consider looking into something general purpose to build on. 2. How is Bayeux "standard" whereas BOSH is "custom"? The XSF is a more > established standards development organization than the Dojo Foundation. > > 3. http://svn.xantus.org/shortbus/trunk/bayeux/bayeux.html says "Copyright > (c) The Dojo Foundation (2007). All Rights Reserved". It's not clear to me how > that is an open standard, absent a more detailed legal notice or IPR policy. > Contrast that to the XSF's IPR policy. Fair enough, "open" was an over statement on my part. Best, Harlan
