[BOSH] more on the need for BOSH

[Peter Saint-Andre]

http://www.atmasphere.net/wp/archives/2008/07/18/nokia-chat has a
comment of interest about the new Nokia Chat application:

"My only problem with it is that it doesn’t include any way to work over
port 80 (http) which is required if you’re behind corporate firewalls
(using wifi) or behind a cheap 3G service (like my 10 Euro flat -
http-only service!)."

BOSH to the rescue? ;-)

/psa

[Adam Pisoni]

So we just rolled out the BOSH version of the secret app I've been
working on. We turned it on provisionally for only certain users.
It's quite badass. Ajax polling is so web 2.0. Anyway, we're
finding that it's literally crashing IE. There's been some talk
about strophe and i'm wondering if I shouldn't try that instead of
JSJaC, or whether others out there haven't had some similar issues
with JSJaC.

Also, has anyone gotten JSJaC working without a proxy, via cross-site
scripting hacks? We're using Nginx to proxy http-bind, and getting
411 Length Required errors when JSJaC tries to resume. We were
going to use our netscaler load balancer to do the proxying, but are
still trying to figure out how to do it right. Do all load balancers
and routers have to be so hard to configure?

thanks,
adam

[Harlan Iverson]

Part of xep-0124 allows cross-domain communication though an alternative
script syntax. I just implemented it in xmpp4js:
http://xmpp4js.sourceforge.net. JSJaC could easily be modified to support it
as well, and I can't speak for strophe. I think it took all of a dozen lines
of code for mine to support it.

Openfire 3.5.2 claims to support script syntax out of the box, but I had to
merge in changes from GSoC/trunk for it to work right. I can't speak for
whether ejabberd supports it, but I would imagine so.

Harlan



On Sat, Jul 19, 2008 at 4:15 PM, Adam Pisoni <apisoni (AT) geni (DOT) com> wrote:

> So we just rolled out the BOSH version of the secret app I've been working
> on. We turned it on provisionally for only certain users. It's quite
> badass. Ajax polling is so web 2.0. Anyway, we're finding that it's
> literally crashing IE. There's been some talk about strophe and i'm
> wondering if I shouldn't try that instead of JSJaC, or whether others out
> there haven't had some similar issues with JSJaC.
>
> Also, has anyone gotten JSJaC working without a proxy, via cross-site
> scripting hacks? We're using Nginx to proxy http-bind, and getting 411
> Length Required errors when JSJaC tries to resume. We were going to use
> our netscaler load balancer to do the proxying, but are still trying to
> figure out how to do it right. Do all load balancers and routers have to
> be so hard to configure?
>
> thanks,
> adam
>
>

[Adam Pisoni]

Thanks for the info. I'm just checking out that section of the XEP
now. How do you think xmpp4js compares to JSJaC. I was under the
impression (wrongfully it seems) that xmpp4js was the older library
and JSJaC was the newer one. When you say you just implemented it in
xmpp4js, do you mean in the trunk or just locally?

adam


On Jul 20, 2008, at 7:12 PM, Harlan Iverson wrote:

> Part of xep-0124 allows cross-domain communication though an
> alternative script syntax. I just implemented it in xmpp4js: http://xmpp4js.sourceforge.net
> . JSJaC could easily be modified to support it as well, and I can't
> speak for strophe. I think it took all of a dozen lines of code for
> mine to support it.
>
> Openfire 3.5.2 claims to support script syntax out of the box, but I
> had to merge in changes from GSoC/trunk for it to work right. I
> can't speak for whether ejabberd supports it, but I would imagine so.
>
> Harlan
>
>
>
> On Sat, Jul 19, 2008 at 4:15 PM, Adam Pisoni <apisoni (AT) geni (DOT) com> wrote:
> So we just rolled out the BOSH version of the secret app I've been
> working on. We turned it on provisionally for only certain users.
> It's quite badass. Ajax polling is so web 2.0. Anyway, we're
> finding that it's literally crashing IE. There's been some talk
> about strophe and i'm wondering if I shouldn't try that instead of
> JSJaC, or whether others out there haven't had some similar issues
> with JSJaC.
>
> Also, has anyone gotten JSJaC working without a proxy, via cross-
> site scripting hacks? We're using Nginx to proxy http-bind, and
> getting 411 Length Required errors when JSJaC tries to resume.
> We were going to use our netscaler load balancer to do the proxying,
> but are still trying to figure out how to do it right. Do all load
> balancers and routers have to be so hard to configure?
>
> thanks,
> adam
>
>

[Harlan Iverson]

Right,

I started xmpp4js about a year ago because JSJaC didn't meet my needs at the
time. The problems I had with it were how tightly coupled things were, and
that it used string manipulation for packets rather than DOM. It seems that
the author has done a lot to it since then and I think I remember seeing it
using DOM, so I'd imagine they are about similar now. On the other hand,
xmpp4js might be more immature; documentation is kind of sparse, it has only
really be used with Openfire, and it might not follow the spec 100% even
though it works. The only 'known' implementation using it right now is
Soashable.

The alternative script syntax is implemented in the public trunk of xmpp4js,
and is live on soashable.com.

Harlan


On Sun, Jul 20, 2008 at 9:37 PM, Adam Pisoni <apisoni (AT) geni (DOT) com> wrote:

> Thanks for the info. I'm just checking out that section of the XEP now.
> How do you think xmpp4js compares to JSJaC. I was under the impression
> (wrongfully it seems) that xmpp4js was the older library and JSJaC was the
> newer one. When you say you just implemented it in xmpp4js, do you mean in
> the trunk or just locally?
>
> adam
>
>

[Adam Pisoni]

I might give xmpp4js a try. JSJaC seems pretty heavy and as I
mentioned, seems to crash IE. If I give xmpp4js a try, I'll let you
know.

Thanks,
adam



On Jul 20, 2008, at 7:53 PM, Harlan Iverson wrote:

> Right,
>
> I started xmpp4js about a year ago because JSJaC didn't meet my
> needs at the time. The problems I had with it were how tightly
> coupled things were, and that it used string manipulation for
> packets rather than DOM. It seems that the author has done a lot to
> it since then and I think I remember seeing it using DOM, so I'd
> imagine they are about similar now. On the other hand, xmpp4js might
> be more immature; documentation is kind of sparse, it has only
> really be used with Openfire, and it might not follow the spec 100%
> even though it works. The only 'known' implementation using it right
> now is Soashable.
>
> The alternative script syntax is implemented in the public trunk of
> xmpp4js, and is live on soashable.com.
>
> Harlan
>
>
> On Sun, Jul 20, 2008 at 9:37 PM, Adam Pisoni <apisoni (AT) geni (DOT) com> wrote:
> Thanks for the info. I'm just checking out that section of the XEP
> now. How do you think xmpp4js compares to JSJaC. I was under the
> impression (wrongfully it seems) that xmpp4js was the older library
> and JSJaC was the newer one. When you say you just implemented it
> in xmpp4js, do you mean in the trunk or just locally?
>
> adam
>
>

[Jack Moffitt]

> Part of xep-0124 allows cross-domain communication though an alternative
> script syntax. I just implemented it in xmpp4js:
> http://xmpp4js.sourceforge.net. JSJaC could easily be modified to support it
> as well, and I can't speak for strophe. I think it took all of a dozen lines
> of code for mine to support it.

We can add it to Strophe pretty easily as well.

One thing that I didn't see mentioned in the spec is that there are
restrictions on the length of GET requests, so the alternative script
syntax actually suffers from quite a serious limitation. I'm pretty
sure it would not work for many common things like getting avatars,
etc.

According to http://www.boutell.com/newfaq/misc/urllength.html the
limit of IE is about 2k characters, which is too small for things
without some changes in how XMPP does rosters and vcard avatars, etc.

It would be nice if the XEP was updated to reflect these limitations.

jack.

[Jack Moffitt]

> Part of xep-0124 allows cross-domain communication though an alternative
> script syntax. I just implemented it in xmpp4js:
> http://xmpp4js.sourceforge.net. JSJaC could easily be modified to support it
> as well, and I can't speak for strophe. I think it took all of a dozen lines
> of code for mine to support it.

We can add it to Strophe pretty easily as well.

One thing that I didn't see mentioned in the spec is that there are
restrictions on the length of GET requests, so the alternative script
syntax actually suffers from quite a serious limitation. I'm pretty
sure it would not work for many common things like getting avatars,
etc.

According to http://www.boutell.com/newfaq/misc/urllength.html the
limit of IE is about 2k characters, which is too small for things
without some changes in how XMPP does rosters and vcard avatars, etc.

It would be nice if the XEP was updated to reflect these limitations.

jack.

[Harlan Iverson]

Actually the XEP does mention the GET request limit in 18.2, just below
example 40 (emphasis mine):

Although RFC 2616 does not limit the length of HTTP URIs, the runtime
> environment of the client might restrict the length of the URI that it can
> include in each GET request. [30<http://www.xmpp.org/extensions/xep-0124.html#nt-id2266059>]
> In these cases the client MUST reduce the content of the <body/> element
> accordingly and send the remaining content in subsequent HTTP GET requests
> wrapped in new <body/> elements (with incremented 'rid' attributes). This is
> possible since, unlike Pure Syntax, with Script Syntax the connection
> manager *MUST treat the string of characters between the opening and
> closing <body> tags of each request as part of an octet stream instead of as
> a set of complete XML stanzas. The content of any one <body/> element MUST
> NOT be parsed in isolation from the rest of the stream*.
>


My interpretation of this is that each <body> can contain partial stanzas
including unclosed tags that are closed subsequent <body>s. xmpp4js does not
currently do this, in part because I am unsure that I'm interpreting it
correctly, and in part because I haven't experienced a limit (though it's
probably a matter of time).

An example illustrating this in the XEP would be useful.

Harlan

On Mon, Jul 21, 2008 at 1:06 PM, Jack Moffitt <jack (AT) chesspark (DOT) com> wrote:

> > Part of xep-0124 allows cross-domain communication though an alternative
> > script syntax. I just implemented it in xmpp4js:
> > http://xmpp4js.sourceforge.net. JSJaC could easily be modified to
> support it
> > as well, and I can't speak for strophe. I think it took all of a dozen
> lines
> > of code for mine to support it.
>
> We can add it to Strophe pretty easily as well.
>
> One thing that I didn't see mentioned in the spec is that there are
> restrictions on the length of GET requests, so the alternative script
> syntax actually suffers from quite a serious limitation. I'm pretty
> sure it would not work for many common things like getting avatars,
> etc.
>
> According to http://www.boutell.com/newfaq/misc/urllength.html the
> limit of IE is about 2k characters, which is too small for things
> without some changes in how XMPP does rosters and vcard avatars, etc.
>
> It would be nice if the XEP was updated to reflect these limitations.
>
> jack.
>

[Peter Saint-Andre]

Harlan Iverson wrote:
> Actually the XEP does mention the GET request limit in 18.2, just below
> example 40 (emphasis mine):
>
> Although RFC 2616 does not limit the length of HTTP URIs, the
> runtime environment of the client might restrict the length of the
> URI that it can include in each GET request. [30
> <http://www.xmpp.org/extensions/xep-0124.html#nt-id2266059>] In
> these cases the client MUST reduce the content of the <body/>
> element accordingly and send the remaining content in subsequent
> HTTP GET requests wrapped in new <body/> elements (with incremented
> 'rid' attributes). This is possible since, unlike Pure Syntax, with
> Script Syntax the connection manager *MUST treat the string of
> characters between the opening and closing <body> tags of each
> request as part of an octet stream instead of as a set of complete
> XML stanzas. The content of any one <body/> element MUST NOT be
> parsed in isolation from the rest of the stream*.
>
>
>
> My interpretation of this is that each <body> can contain partial
> stanzas including unclosed tags that are closed subsequent <body>s.
> xmpp4js does not currently do this, in part because I am unsure that I'm
> interpreting it correctly, and in part because I haven't experienced a
> limit (though it's probably a matter of time).
>
> An example illustrating this in the XEP would be useful.

I'm happy to add an example of this.

/psa