Yes, both are noted. This JS/JSON object format carries all data as XML but is more compact than json.org reference converters.
Didi use XMLHttpRequest parsed by browser and couldn't find proper way to handle this XML-object without some glue logic to make it to work properly. And this was browser dependent behaviour. Yes, json2.js is quite slow, but mostly relevant for IE-family of browsers. But let's not forget Chrome/Chromium, Safari and other WebKit derivates which are more ToT stuff. Some do use old browsers, time likely will heal that "problem" when cool web application generally just don't run on those. Your point about multiple iq's etc is valid, I forgot to define that in that case iq object is converted to object array. So there can be iq with singular object value or array of values. Each carry their properties in "_" object. Cheers, -Mika On Sat, 2010-01-02 at 01:23 +0100, ext Waqas Hussain wrote: > On Thu, Dec 31, 2009 at 3:40 PM, Helander Mika (Nokia-S/Oulu) > <[email protected]> wrote: > > > Btw, no-one commented my thinking to use JSON directly with > BOSH, still > this has been evolving a bit since original post. > > > > > While certainly interesting, there are several points I'd like to > criticize. > > > 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. > > > > > Browsers as old as IE5 came with a native XML parser, usable from > javascript. Unless you include eval(), they did not come with a JSON > parser. The json2.js fallback is quite slow. > > > 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. > > > > > Problem with the above: In your first example, the <iq/> has a <bind/> > child, correct? Your conversion doesn't work if there are multiple > children with the same name (e.g., SASL the mechanisms list), or if > the order of the children needs to be preserved (e.g., multiple > stanzas in a BOSH response, XHTML-IM). Any XML-to-JSON mapping you > decide on needs to capture all information about the XML, including > ordering, namespaces, etc. > > > 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. > > > > > That's because you are probably doing it wrong. Why are you parsing > the XML manually? First, don't manually parse XML. The XMLHttpRequest > object does this for you, automatically. And it isn't slow. > > > Second, while yes, there are differences in DOM support in browsers, > for the XML DOM (as opposed to the HTML DOM), these are minor. Most > behavior regarding XML is relatively consistent across browsers. > > > I don't see a problem with clients passing whitespace between tags. > Whitespace isn't always insignificant, and XML parsers don't (and > shouldn't) strip it away. A server which strips away all whitespace > would be breaking the XMPP spec. > > > There are certain benefits with using XML (as opposed to JSON). With > XML, you get to use XPath. The XPath API isn't consistent in older > browsers, but it would probably perform faster than any manual > searching you do in a JSON object. And if you dislike the DOM, that's > the problem jQuery was designed to solve. > > > Cheers, > -Mika > > > > > > > -- > Waqas Hussain >
