Harlan Iverson wrote:
On Mon, Jul 28, 2008 at 9:35 PM, Jack Moffitt <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:> Suggestions from many forums is to use a synchronous xhr > connection in unload, which could work for normal BOSH but not script syntax > (which my app will be using for xdomain properties). Be aware that we are planning on removing the alternative script syntax from the spec. There are a lot of hidden gotchas. At the XMPP Summit, we realized that it hadn't been sufficiently specced and should never have been added to a mature XEP anyway.Hmmm, interesting. Would you mind summing up the known gotchas for those of us who didn't make it to the summit?
I really need to write up some minutes while it's still fresh...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.
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?
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).
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 © 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.
That said, it might be good to design a common protocol that could be used by everyone. Is there an appropriate mailing list or discussion forum?
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
