There are a couple of issues which come to mind - others (Peter, Ian, etc) can comment better though.
a) The proposal is essentially attempting to convert xml to json & back (at CM) - imo this mapping is not trivial : assuming ofcourse a general mapping does not exist already. This includes necessary escaping of content within the payload so that it does not get interpreted by json & xml parser, entities, etc. b) The assumption made is json is available at the clients If the client is not a javascript client, then json binding would pretty much be a bad overhead - so I am assuming this is targetted specifically at browsers I guess ? Ofcourse there are security implication of eval'ing js, etc - which others are more authoritative in commenting about. Regards, Mridul ----- Original Message ---- > From: Helander Mika (Nokia-S/Oulu) <[email protected]> > To: Bidirectional Streams Over Synchronous HTTP <[email protected]> > Sent: Thu, 31 December, 2009 4:10:50 PM > Subject: Re: [BOSH] Pipelining / avoiding use of 2x HTTP-sockets > > 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 "value ") > 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) > > wrote: > > > > > From: Helander Mika (Nokia-S/Oulu) > > > 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 --- > > > > > > > > > xmlns='urn:ietf:params:xml:ns:xmpp-bind'> > > > someresource > > > > > > > > > --- 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/ The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/
