View Full Version : [BOSH] session pause during onbeforeunload
Harlan Iverson
07-28-2008, 08:25 PM
I'm attempting to make a session pause in the onbeforeunload event but
running into issues with the browser prematurely closing connections (both
xhr and script). Here is roughly the series of events:
app.onPageUnload()
con.pause( 120 )
beforepause handler: con.send( new Message( "me (AT) example (DOT) com", "brb..." )
)
con.send( "<body rid="1234" pause="120" .../>" )
lastRid = 1234 // the RID of the last packet; the pause request
=== reload page ===
app.onPageLoad()
con.resume( lastRid (=1234), etc )
con.send( "<body rid="1235" .../>" ) // first request, poll or normal;
the RID after the pause request
resume handler: con.send( new Message( "me (AT) example (DOT) com", "back" ) )
This works as expected if i manually call app.onPageUnload(), refresh the
page, and call app.onPageLoad(). But as soon as I have app.onPageUnload()
called from the onbeforeunload handler of the page, all script and xhr
connections seem to prematurely close. Also, I get correct behavior if I put
a breakpoint after all requests are sent in the app.onPageUnload function
(ie connections are left open long enough to fully transmit their contents).
If connections prematurely close but I decrement the rid by 1 on the resume
request then the connection resumes as expected.
Since this works as expected outside the onbeforeunload handler, I assume
that the problem is unexpected behavior due to connections closing
prematurely.
Does anyone have ideas for how to work around this?
Thanks,
Harlan
Jack Moffitt
07-28-2008, 08:55 PM
> Does anyone have ideas for how to work around this?
We aren't trying anything as ambitious as pausing in unbeforeunload,
and we have not gotten that event handler to work reliably cross
browser. As I recall, and maybe collin can correct me, only IE really
supports this well. I hope I am wrong, and look forward to other
people's suggestions/solutions to the problem.
jack.
Collin Grady
07-28-2008, 09:17 PM
Jack Moffitt said the following:
>> Does anyone have ideas for how to work around this?
>
> We aren't trying anything as ambitious as pausing in unbeforeunload,
> and we have not gotten that event handler to work reliably cross
> browser. As I recall, and maybe collin can correct me, only IE really
> supports this well. I hope I am wrong, and look forward to other
> people's suggestions/solutions to the problem.
beforeunload works sometimes in non-IE browsers, but not all, and in some, not
all the time - we had to hook both beforeunload and unload to get our handler
firing as reliable as possible
--
Collin Grady
Harlan Iverson
07-28-2008, 10:24 PM
On Mon, Jul 28, 2008 at 2:15 PM, Collin Grady <collin (AT) collingrady (DOT) com>wrote:
> Jack Moffitt said the following:
>
> Does anyone have ideas for how to work around this?
>>>
>>
>> We aren't trying anything as ambitious as pausing in unbeforeunload,
>> and we have not gotten that event handler to work reliably cross
>> browser. As I recall, and maybe collin can correct me, only IE really
>> supports this well. I hope I am wrong, and look forward to other
>> people's suggestions/solutions to the problem.
>>
>
> beforeunload works sometimes in non-IE browsers, but not all, and in some,
> not all the time - we had to hook both beforeunload and unload to get our
> handler firing as reliable as possible
>
mmm, interesting. I guess I should have done my homework before trying this
approach =]. 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).
Can you elaborate on the dual-handler method and how reliable it is, and
possibly give a code example?
A thought that I just had: what if my app just always keeps track of the
sid/rid/keys in a cookie/localStorage and checks for that during
construction on the connection in the next page load? In fact, I could even
call resume() as normal since all a pause does is temporarily extend 'wait',
and resume just loads up the state with a serialized object returned by
pause. With a long enough 'wait' specified, it should work. Though I would
consider this a hack =[.
Collin Grady
07-29-2008, 12:53 AM
Harlan Iverson said the following:
> Can you elaborate on the dual-handler method and how reliable it is, and
> possibly give a code example?
I don't remember exact stats, but it ended up being pretty reliable across
browsers for our needs in disconnecting on a window close - the rare instance of
it not working just had them online for a bit before timing out.
This is a quick example:
function windowOnUnload (ev) {
if (window.app)
app.disconnect();
}
function windowOnBeforeUnload (ev) {
if (window.app)
app.disconnect();
}
util_addEventListener("unload", window, windowOnUnload);
window.onbeforeunload = windowOnBeforeUnload;
util_addEventListener is just a wrapper for using attachEvent/addEventListener
in the right browsers - another quirk to note here is that onbeforeunload
doesn't work properly with those functions, which is why it's being set differently.
--
Collin Grady
Harlan Iverson
07-29-2008, 02:54 AM
> I don't remember exact stats, but it ended up being pretty reliable across
> browsers for our needs in disconnecting on a window close - the rare
> instance of it not working just had them online for a bit before timing out.
>
>
>
Ah, okay, so this really just uses brute force to ensure that the connection
is disconnected; gracefully if possible, timeout if not? Works for that use
case, not so much for trying to send a last pause request and accurately
capture state to resume in the next page.
Also, just an update: I tried adding a flag in my library, isPausing, and
setting it to true when pause is called. Then any new request while
isPausing is true is synchronous, but that resulted in getting stuck on the
unresponsive page for 60 seconds.
Out of curiosity, was browser unload the use case in mind when pause support
was added to the spec?
Jack Moffitt
07-29-2008, 04:37 AM
> 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.
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.
jack.
Harlan Iverson
07-29-2008, 05:47 AM
On Mon, Jul 28, 2008 at 9:35 PM, Jack Moffitt <jack (AT) chesspark (DOT) com> 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 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.
>
>
> 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.
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?
Harlan
Peter Saint-Andre
07-29-2008, 06:19 AM
Harlan Iverson wrote:
>
>
> On Mon, Jul 28, 2008 at 9:35 PM, Jack Moffitt <jack (AT) chesspark (DOT) com
> <mailto:jack (AT) chesspark (DOT) com>> 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
Jack Moffitt
07-29-2008, 06:19 AM
> 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.
Harlan Iverson
07-29-2008, 06:46 AM
>
>
> 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
Peter Saint-Andre
07-29-2008, 06:49 AM
Harlan Iverson wrote:
>
>
>
> 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> <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 © 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.
Don't mind me, I just get a bit grumpy when people say everything is a
standard except what the XSF produces. :)
/psa
Harlan Iverson
07-29-2008, 06:56 AM
On Mon, Jul 28, 2008 at 11:18 PM, Jack Moffitt <jack (AT) chesspark (DOT) com> 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
Jack Moffitt
07-29-2008, 07:52 AM
> The server can use a sax parser, they do work on streams; there is no magic
> required.
Using a SAX parser does not tell you where the data ends. This may be
irrelevant.
> 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).
Ok, I am grokking it now. In my mental model the server was having to
receive all partial requests to start processing. With sax style
parsing you can support resends. This still puts more burden on the
client to split up data. (As a side note, splitting up data is needed
in general to handle very large single stanzas, but this cannot be
done inside the current BOSH spec I don't think).
In any case, ASS is a giant hack, and one that is avoidable by using
some other way to do the cross site stuff. This is a hot topic in
AJAX land at the moment, and I'm sure another solution will be
forthcoming. It should have never made it into the
already-at-Draft-status BOSH XEPs and should be moved to a historic or
experimental xep.
I'm pretty sure the other cross site solutions will not be BOSH
specific, and so will not need a XEP of their own, unless we do an
informational one.
Personally, I don't see the single domain limitation as being that
bad. There is nothing preventing you from proxying Punjab behind
nginx and connecting to any jabber server you want that way. I know
Blaine had a use case or two that required a separate domain, but this
seems limited to extreme cases like Twitter scalability levels. Even
then I'm not sure it is absolutely necessary, or just a big
convenience.
Note that flash has similar limitations as well. I talked with
Fritzy about Seesmic's AS3 XMPP implementation, and that limits you to
a local jabber server IIRC. I suppose you could get around that with
a jabber proxy too, which is essentially all BOSH is.
jack.
Harlan Iverson
07-29-2008, 04:39 PM
> In any case, ASS is a giant hack, and one that is avoidable by using
> some other way to do the cross site stuff. This is a hot topic in
> AJAX land at the moment, and I'm sure another solution will be
> forthcoming. It should have never made it into the
> already-at-Draft-status BOSH XEPs and should be moved to a historic or
> experimental xep.
>
I don't disagree. Like I said, not trying to be an apologist for it; just
explaining what I think of it =]
>
> I'm pretty sure the other cross site solutions will not be BOSH
> specific, and so will not need a XEP of their own, unless we do an
> informational one.
I think it's important that it be based on something that people can agree
on rather than everyone rolling their own slightly different solution.
Experimental / informal XEP if necessary.
>
>
> Personally, I don't see the single domain limitation as being that
> bad. There is nothing preventing you from proxying Punjab behind
> nginx and connecting to any jabber server you want that way. I know
> Blaine had a use case or two that required a separate domain, but this
> seems limited to extreme cases like Twitter scalability levels. Even
> then I'm not sure it is absolutely necessary, or just a big
> convenience.
It isn't even an extreme case that calls for it. Say you have $9/mo hosting
and you don't know anything about servers (or don't have sufficient
privileges), but you want to put Social Widget X on your page. With XSS, you
can consume a completely hosted solution; <script src="
http://socialwidgetx.com/embed.js" ...> which then makes a 'connection'
using BOSH or Protocol Y to http://bosh.socialwidgetx.com/. How it
accomplishes this I don't mind, as we can agree that this is a legit case
and solve it =]
> Note that flash has similar limitations as well. I talked with
> Fritzy about Seesmic's AS3 XMPP implementation, and that limits you to
> a local jabber server IIRC. I suppose you could get around that with
> a jabber proxy too, which is essentially all BOSH is.
>
>
Flash can overcome the same-origin policy with crossdomain.xml. I've read
that browsers may be adopting some mechanisms in the future that will be
more friendly to the use case that I'm thinking of such as cross window
messaging, x-domain policy headers, and others.
But for the time being browsers don't commonly support such things and so
some browser-specific workaround is needed. Specifying or using something
Bayeux-like that negotiates transport mechanisms would allow future
expandability as well; the next few years of browser features is going to be
interesting and fast changing.
Best,
Harlan
Peter Saint-Andre
07-29-2008, 04:45 PM
Jack Moffitt wrote:
> In any case, ASS is a giant hack
And perhaps it would have been smart to avoid any technology called
"ASS" in the first place! ;-)
/psa
Harlan Iverson
07-29-2008, 04:46 PM
>
>
> In any case, ASS is a giant hack
>>
>
> And perhaps it would have been smart to avoid any technology called "ASS"
> in the first place! ;-)
>
zing!
Harlan Iverson
08-01-2008, 11:05 PM
And just to kick the dead horse a little more ;), I sent a message to the
whatwg list about pause/resume in WebSocket:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/015545.html
Even though this is looking very far forward, there is the orbited (
http://www.orbited.org/) project which implements WebSockets and works using
regular comet + twisted today.
I think this would avoid any XMPP extension at all, and would purely be
servers or proxies adding WebSocket support.
Harlan
vBulletin® v3.8.0 Release Candidate 2, Copyright ©2000-2009, Jelsoft Enterprises Ltd.