[Laszlo-dev] JSON RPC

[Henry Minsky]

well said, Don


>
>    1.
>
>    Don Hopkins <http://www.DonHopkins.com> said,
>
>    December 20, 2006 at 1:42 pm<http://scripting.wordpress.com/2006/12/20/scripting-news-for-12202006/#comment-26362>
>
>    Dave, I would have expected you to be one of the first people to
>    understand an appreciate the strengths of JSON, because they are so
>    practical and simple.
>
>    One huge practical advantage to JSON over XML in the web browser is
>    that you can load JavaScript from any site, while you're restricted in which
>    sites you can load XML from. I have no idea why browsers insist on limiting
>    where you can load non-executable XML from, when they don't bother to limit
>    where you can load executable JavaScript from, but there you go: that's how
>    it is, and there's nothing anybody can do about it. JSON nicely works around
>    that limitation, instead of holding its breath and waiting until the world
>    comes around to being fair. Surely you can appreciate that practical
>    advantage.
>
>    Another practical advantage is that it JSON is the absolutely
>    fastest way to convert text data into a usable native format. Even if the
>    XML parser could be as fastas the JavaScript parser, it parses the text into
>    many fluffy XML DOM nodes (possibly including text nodes for intermediate
>    white space you have to skip over), which is yet another layer your code has
>    to go through to get any useful work done. Instead, JSON parsing DIRECTLY
>    results in tight JavaScript data, which is the most optimal format for
>    processing with JavaScript, with no wasteful layers of indirection and
>    generic DOM apis that require lots of effort for extraction and type
>    conversion. XPath expressions and DOM access are NEVER going to be as fast
>    as direct array access in JavaScript. JSON simply has fewer layers than XML,
>    so it's way faster and uses much less memory, and it's easier to use because
>    you hve direct access built into the language, instead accessing data
>    through a DOM api.
>
>    The other advantage is that it's a more-or-less universal lowest
>    common denominator between languages, high enough to be useful, but not too
>    low. XML has many features than most languages don't support and many
>    applications don't need, because they're really just working with arrays and
>    dictionaries, and don't need all the features of XML.
>
>    JSON makes it possible to use a bunch of different languages
>    together easily. And there's no way to get around the fact that JavaScript
>    totally rules in the web browser, but has a lot of quirky weaknesses that
>    must be worked around. And JSON serves both purposes quite practically
>    (interoperating with other languages, while taking advantage of JavaScript
>    peculiarities and working around its limitations). And it's that practical
>    approach that I would have expected you to appreciate.
>
>    -Don
>
>
>
>    1.
>
>    Don Hopkins <http://www.DonHopkins.com> said,
>
>    December 20, 2006 at 2:08 pm<http://scripting.wordpress.com/2006/12/20/scripting-news-for-12202006/#comment-26373>
>
>    Just to be fair, there are some wrinkles in JSON's universality.
>
>    Here is a possible weakness with PHP processing JSON: PHP arrays are
>    the same as PHP dictionaries, so how does PHP know how to convert an empty
>    array/dict to JSON, so that it can survive a round trip without changing
>    type?
>
>    If I read in the json [] to PHP, then write it back out, how does
>    PHP know to write out {} or [], since they are the same to PHP, which has no
>    separate dict and array types? The same problem applies to dictionaries
>    whose keys just happen to be consecutive integers, but the zero length array
>    and dictionary are a more common example.
>
>    Another wrinkle in JSON's universality is that the Flash player does
>    not have a built-in JavaScript parser, so in Flash's version of JavaScript,
>    JSON does not have the advantage that it's trivially easy and efficient to
>    parse. (People have written JSON parsers in Flash of course, but they're
>    nowhere near as fast as the built-in XML parser.)
>
>    So in Flash, XML is still the preferred format, but it still uses a
>    lot of memory: The Flash XML parser parses XML into JavaScript data
>    structures that are more complex than JSON (twice the number of layers,
>    three times the number of structures. An XML node gets parsed into an object
>    with an attributes sub-dictionary and a contents sub-array).
>
>    The absolute most efficient way to load data into Flash is by
>    loading and executing compiled binary SWF files, which can contain
>    executable byte codes and binary literals that directly creates the data
>    structures you want to send.
>
>    If you want to minimize the amount of data sent to the Flash client,
>    the server can encode XML (or JSON) as a SWF file, and send it as compressed
>    binary data.
>
>    The OpenLaszlo's server can compile XML and JSON into SWF, because
>    years ago Flash's XML parser was much slower, so it was worth parsing the
>    XML on the server side (plus the added advantage that the server could proxy
>    XML from any domain). But now Flash's XML parser is much better, so it's
>    more efficient to download XML text to parse in Flash.
>
>    However Flash still has its own restrictions on which domains you
>    can download SWF or XML from, so Flash can't take advantage of browser-based
>    JavaScript's ability to load JSON from any domain. So because of Flash's
>    restrictions (and browser bugs like IE6's refusal to deliver compressed http
>    content to plug-ins), you sometimes end up having to write a server-side
>    proxy anyway, instead of downloading XML directly into the Flash player.
>
>    -Don
>
>
>
>
>


-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20070105/dad114cf/attachment.html