Yes, I was forced to implement multi-XHR handling like all other JS impl
for BOSH. By using "requests" of 2 and carefully selected value in
"wait" it is possible to minimize burden caused by multiple SSL sockets
per client and still keep implementation reactive.
Btw, no-one commented my thinking to use JSON directly with BOSH, still
this has been evolving a bit since original post.
Now content-type used is "application/jsonrequest".
Current browsers support natively JSON class including JSON.parse() and
JSON.stringify() which eases up alot implementation for this.
As fallback json2.js from json.org is to be used in browsers not having
that supported natively.
And JS-object was "optimized" a bit as follows:
--- JS-object ---
{ iq: { _: { type: "set", id: "bind_2" },
bind: { _: { xmlns: "urn:ietf:params:xml:ns:xmpp-bind" },
resource: "someresource" }
}
}
---
Also for stanzas having attributes and "direct" value following was also
needed (note, double-underline for such as value for auth below):
--- JS-object ---
{ auth: { _: { xmlns : "urn:ietf:params:xml:ns:xmpp-sasl",
mechanism: "PLAIN" },
__: "bW..." }
}
---
When above objects are JSON.stringify()'d they become:
--- JSON ---
{"auth":{"_":{"xmlns":"urn:ietf:params:xml:ns:xmpp-sasl","mechanism":"PLAIN"},"__":"bW..."}}
---
This "optimization" keeps JSON in-wire compact enough compared to
standard XML and enables use of lightweight JavaScript stack for
processing.
And, have to say, XML parsing is not fun in browser, especially because
of differences in XML/DOM support of different browsers. For example
some clients (and/or XMPP-servers) pass through XML which contains white
spaces and/or newlines in between tags (like "<t>value</t> <t2/>")
which are in some cases quite hard to tackle.
Cheers,
-Mika
On Wed, 2009-12-30 at 16:47 +0100, ext Mridul Muralidharan wrote:
> Ian should really write up some document describing the way 124 is
> supposed to work, I have seen it confusing quite a lot of people.
>
>
> 124 requires that when client wants to send a request, it should be
> able to as soon as possible : since the previous request from client
> would typically be blocked at CM if there is no response to be
> returned.
>
> This means that :
> a) Client uses 'another' connection to talk to CM.
> In this case, CM will immediately respond back on the previous
> connection and 'block' on the new connection (for returning responses
> with minimum delay when server needs to send async messages back).
> b) If client uses same socket (for whatever reason : pipelining POST's
> is really weird behavior IIRC), then CM should detect availability of
> a new request from client and send a response back for the previous
> request.
>
> (b) is not required since most, if not all, impl's do not pipeline
> post requests.
>
>
>
> Hope this clarifies things.
> Sorry for the late response - probably not relevant anymore !
>
> Regards,
> Mridul
>
>
> --- On Tue, 13/10/09, Helander Mika (Nokia-S/Oulu)
> <[email protected]> wrote:
>
> > From: Helander Mika (Nokia-S/Oulu) <[email protected]>
> > Subject: [BOSH] Pipelining / avoiding use of 2x HTTP-sockets
> > To: [email protected]
> > Date: Tuesday, 13 October, 2009, 10:31 PM
> >
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> >
> >
> > I've been coding own implementation of BOSH for
> > Ajax-capable web browsers.
> >
> >
> >
> > First design rule is to make it functional, then optimize
> > it. Optimization of course covers both amount of JS code
> > running in browser, and in-wire optimization of data
> > traffic.
> >
> >
> >
> > First pipelining:
> >
> >
> >
> > As XEP-0124 states, in principle, it's possible to use
> > http-pipelining and so just one http/https connection to
> > BOSH. Unfortunately this seems impossible due the nature of
> > current browsers.
> >
> >
> >
> > In Firefox pipelining could be enabled but programmable use
> > of it is very hard, if impossible. I couldn't find any
> > good references of succesfull implementations.
> >
> > For other browsers things get even more hairy. Outside
> > browsers this is likely possible but outside this scope.
> >
> >
> >
> > The fallback is of course to use two (or up to max
> > permitted by BOSH server) connections but this increases
> > BOSH server load considerably, especially if https is used
> > to secure connection (and in some cases to deflate downlink
> > data).
> >
> >
> >
> > Someone was considering http chunking for comet to stick in
> > single connection and improve 2-way comms.
> >
> >
> >
> > Is there any JS examples or references to handle (BOSH-)
> > sockets the most efficient way, ultimately with single
> > XMLHttpRequest connection ?
> >
> >
> >
> > Then in-wire and JS-side optimization:
> >
> >
> >
> > Parsing XML in JS is possible but unnecessarily complicates
> > stanza handling and adds up considerably amount of JS code
> > running in browser.
> >
> >
> >
> > My decision was to convert stanzas to JS-object for (much)
> > easier processing later on. This happens of course for both
> > directions.
> >
> >
> >
> > Because of nature of XMPP stanzas, and my goal to avoid use
> > of existing and more generic libraries for xml (or BOSH)
> > ended up to following kind of stanza representation:
> >
> >
> >
> >
> > --- XMPP ---
> > <iq type='set' id='bind_2'>
> > <bind
> > xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
> > <resource>someresource</resource>
> > </bind>
> > </iq>
> > --- JS-object ---
> > { iq: { _iq: { type: "set", id:
> > "bind_2" },
> > bind: { _bind: { xmlns:
> > "urn:ietf:params:xml:ns:xmpp-bind" },
> > resource: "someresource"
> > }
> > }
> > }
> > ---
> >
> > Writing parser for JS-object above was not too complicated.
> > Actually it would be much nicer to have BOSH server to
> > support both Content-Type: 'text/xml; charset=utf-8'
> > and 'application/json' directly.
> >
> >
> >
> > Best approach might be to try json content type with
> > session creation request and if not supported then (load JS
> > and) use fall-back method of xml representation with
> > object-xml conversion.
> >
> >
> >
> > Any comments about that ?
> >
> >
> >
> > Cheers,
> >
> > -Mika
> >
> >
> >
>
>
> The INTERNET now has a personality. YOURS! See your Yahoo!
> Homepage. http://in.yahoo.com/
