Re: [Laszlo-dev] JSON RPC

[Don Hopkins]

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  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 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 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 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, and damn, IT’S NOT EVEN XML! As Dr Phil asks — 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. 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. Don Hopkins said, December 20, 2006 at 1:42 pm 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 Don Hopkins said, December 20, 2006 at 2:08 pm 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