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
