[Laszlo-dev] JSON RPC
Don Hopkins
dhopkins at DonHopkins.com
Fri Jan 5 20:23:13 PST 2007
Here's some discussion from Dave Winer's blog about JSON. He
pooh-pooh'ed JSON because it wasn't XML/RPC, and I and others pointed
out some of its strengths and weaknesses, especially w.r.t. the Flash
player:
http://scripting.wordpress.com/2006/12/20/scripting-news-for-12202006/
*God bless the re-inventers*
<http://www.scripting.com/2006/12/20.html#godBlessTheReinventers>
Gotta love em, because there's no way they're going to stop breaking
what works, and fixing what don't need no fixing.
I've been hearing, off in the distance, about something called JSON,
that proposes to solve a problem that was neatly solved by XML-RPC
<http://www.xmlrpc.com/spec> in 1998, the encoding of arrays and structs
in a format that could easily be processed by all programming languages.
The advantage being that you could easily support the protocol in any
language that supported XML and HTTP, which, at the time, was quickly
becoming all languages.
Then came SOAP, a re-invention of XML-RPC, that I saw as the inevitable
fussing that BigTechCo's feel they have to do to give their software
lock-in, make it impossible for another developer to reverse-engineer
the profile they used, and make the documentation so broad and
incomprehensible that it's impossible to ever completely implement it.
Competition-free open protocols. Microsoft and IBM succeeded at that,
with help from Sun, leading to a backlash, some of it well-intentioned,
and some of it hypocritically promoted by the very same people who made
SOAP so difficult to program! Such chutzpah, but already the users were
so confused they thought it was just geeks being difficult.
I said it then, you'd still need to come up with an object serialization
format for REST apps, otherwise every app has to start from scratch,
they could have used the one SOAP used (we defined a profile
<http://www.soapware.org/bdg> called the Busy Developer's Guide to make
that possible), or god forbid, use the original one in XML-RPC, but
maybe the new devs at various big Silicon Valley companies never heard
about these proto-standards, or chose to re-invent anyway. They came up
with this thing called JSON, that I kept saying to myself, "You don't
even want to look."
Today I looked. I read on Niall Kennedy
<http://www.niallkennedy.com/blog/archives/2006/12/delicious-url-api.html>
that del.icio.us has come up with an API that returns a JSON structure,
and I figured, sheez it can't be that hard to parse, so let's see what
it looks like
<http://badges.del.icio.us/feeds/json/url/blogbadge?hash=742e44bd5d0ccfd3c64f07d226749079>,
and damn, /IT'S NOT EVEN XML!/
As Dr Phil asks
<http://www.scripting.com/2006/12/19.html#twoNotesAboutTvShows> --- What
were they thinking?
No doubt I can write a routine to parse this, but look at how deep they
went to re-invent, XML itself wasn't good enough for them, for some
reason (I'd love to hear the reason). Who did this travesty? Let's find
a tree and string them up. Now.
Ladies and gentlemen, boys and girls, this is why I'm fed up with
Mountain View, Cupertino, Redwood Shores and Redmond. Give me Berkeley
and New York any day. Silicon Valley is made up of little boys pulling
their puds, constantly making love to each other, pretending the world
revolves around them.
End of rant.
Discuss here
<http://scripting.wordpress.com/2006/12/20/scripting-news-for-12202006/#comment-26223>.
Note --- it's an incredible thread, proof that there's still a bunch of
minds in the loop here. I'll probably write up a summary of what we
learned tomorrow. Thanks.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20070105/47476fca/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: leftArrow.gif
Type: image/gif
Size: 886 bytes
Desc: not available
Url : http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20070105/47476fca/leftArrow-0001.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tilted.jpg
Type: image/jpeg
Size: 2282 bytes
Desc: not available
Url : http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20070105/47476fca/tilted-0001.jpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: yankeeFan.jpg
Type: image/jpeg
Size: 4165 bytes
Desc: not available
Url : http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20070105/47476fca/yankeeFan-0001.jpg
More information about the Laszlo-dev
mailing list