Slashdot Mirror

free to use unless you intend to kill people.

See JSON license. "The Software shall be used for Good, not Evil."

It's probably noteworthy to point out that programs under that license is not accepted in at least Debian.
https://wiki.debian.org/qa.deb...

free to use unless you intend to kill people.

See JSON license. "The Software shall be used for Good, not Evil."

{
    CustomerId : "ABCDEF012938487432112424242322426",
    AllowExtendedConfiguation: "true",
    IsMaximumLengthRequired : "true"
}

This is not valid JSON : keys must be encoded.

And it it inefficient to send boolean values as strings instead of booleans because that data type is fully supported in JSON.

{
        "CustomerId": "ABCDEF012938487432112424242322426",
        "AllowExtendedConfiguation": true,
        "IsMaximumLengthRequired": true
}

the way JSON stores represents dates is just aweful

Full of awe? Anyway, as per the spec, dates are not supported as a value. Some implementations incorrectly use something like "new Date(2013, 0, 7)" to store dates, but this is officially not sanctioned and might not work as intended. But really, if you are storing dates in JSON (or anywhere else where a native date object is not available), there's only one format. You can sort by it in the string form, and get a date object simply by using new Date(isoStr).

JSON is not propietary. http://www.json.org/license.html

Oh wow. I see a crisis brewing.

JSON license:

The Software shall be used for Good, not Evil.

Open Source Definition:

6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

Waaaah! Theo de Raadt wants his baby mulching machines to exchange information with JSON, but he can't do that, because evil is banned!

<flamebait type="merely sarcastic" expressedusing="XML" ref="Apple" hence="on topic">Plus, if evil is banned, why the hell is Apple using JSON? On the frigging iPhone????</flamebait> =)

What exactly are "good" and "evil" in this context, anyway? If it is such a big point that it warrants a mention in the license, why isn't it defined clearly?

Yup, proprietary.

Well that explains why proprietary alternatives to XML like JSON or YAML are so much better!

JSON is not propietary.
http://www.json.org/license.html

Nor is YAML
http://www.yaml.de/en/license/license-conditions.html

Or is there a woosh here that I am missing?

I propose to use JSON in all ajax-style applications instead of XML.

I can agree for that particular use case.

It's superior in nearly every way.

Depends on the usage. See below.

You'd be surprised how many ready-made parsers there are at json.org.

So, how do I pick the best one (or at least the "good enough" one) to use? The one that I can trust to be fully compliant, and that will be kept maintained and ported to new language/framework versions? Let's say, I need one for C++.

That's not necessarily true...

You misunderstand me. What I meant is that there are kinds of XML documents in which tags take up the minority of the content, and the majority is text. XHTML is a classic example; DocBook is another one. Essentially any scenario in which the basis is text, and the tags are markup on that text. Your SCORM example (that brings back some very unpleasant memories, by the way - I had to deal with this cursed thing) is about as far from it as it can get.

Now, for text markup, you can still represent it as JSON (after all, it's still a tree) - but just imagine how messy even a simple XHTML example would look that way.

Oh, by the way - JSON sample code in your post isn't actually JSON. In particular, you need to quote all keys, i.e. rather than:

      identifier: "resource1"

you have to write:

      "identifier": "resource1"

The only unquoted JSON identifiers are literals "true", "false", and "null". See RFC 4627 for reference (though the grammar on http://json.org/ also covers this).

see json.org... it's pretty good already. Though having an in-browser JSON.stringify and parse will probably operate better, and safer. I think that adding the toISOString to dates, and including that format in the parser would probably be a nice built-in add, but there are examples in the json.org parser/encoder already.

And your own appeal to authority would work better if you had a little more respect for the most popular LISP dialect in the world. Seriously.

But consider two things: First, the storage is JSON (not JavaScript), and I don't actually know that it's the on-disk format (I doubt it), only that it's the format exposed to developers. What would you use in place of it, for a schema-free database? XML? ASN.1? Serialized objects in $my_favorite_language?

And for what it's worth, JSON is not just Javascript -- it's also valid notation (as in, you can pipe it through eval, if you really want to) for Python, Ruby 1.9, and probably others I don't know about.

The only better candidate I can think of is YAML, which is more complex to parse, and a superset of JSON anyway.

Second, the views (sort of a query language) aren't necessarily Javascript. It's true, Javascript is the default view format, but it can actually be any language that can operate on text sent via a Unix pipe. I hear Python developers are using it with some success.

But given the choice, would you rather write SQL than JavaScript? Really?

Of course, it also has the nice side effect that you can write an entire application in JavaScript, using AJAX, talking directly to the CouchDB server. But I'm guessing that's a side effect, not the real reason Javascript was chosen.

Wait, Slashdot told me that Foxconn was in the hole for Microsoft, purposely sabotaging Linux so Windows can live on! But now they're releasing a fix?

Finish reading the summary:

(which turned out to be the AMI BIOS that several board makers use)

{"TinfoilHat":"
It looks like the AMI BIOS manufacturer is the one who's really purposely sabotaging Linux.
"} // I've had it with XML jokes -- this one's JSON.

Of course you have to convert it to/from strings, duh, you can't put an abstract concept like an object on a wire and send it across the internet. So we represent the object some other way. A string is a perfectly fine way.

And -- Oh -- it's a string which which contains a JavaScript object literal. Now, what do you call the language subset which defines the string appearance of a Javascript object literal? JavaScript Object Notation seems pretty damned reasonable.

Don't like calling eval() to parse the object literal? Why not? It's an object literal; to turn ANY piece of source code (and that's what it is, source code for an object) you need to run a parser over it. It turns out that eval() is a pretty damned good JavaScript parser.

You could, if you we were so inclined, parse the JavaScript yourself. And, in fact, if you only wanted to support objects -- not the whole JavaScript language -- you might want to only parse a limited subset of JavaScript, which some freaky has guy (who works at Yahoo) has decided to call JSON.

Now, what's the best way to write a limited-function parser in JavaScript, and still have it be really fast?

Use native constructs.

Hmm, but does JavaScript have any native constructs which allow us to easily build parsers which understand small regular grammars? Hint: there's a reason they're called regular expressions.

So, the current common/secure technique is to use a regexp parser to validate the input to eval(), because that's the fastest way (two calls, both into native code).

Now, how the hell can we MAKE these objects? Well, it's pretty easy from JavaScript; the .toSource() method and/or uneval calls work pretty good.

So, we now have a general-purpose way to serialize/deserialize javascript objects into something we can send over a network. If you wanted to, that's enough to start a cult and try to build a career around. You could even describe it really complicatedly (like on http://www.json.org/). Or, you could build a compilcated object/class hierarchy around it, like this guy http://www.devpro.it/JSON/files/JSON-js.html -- I suppose you could even come up with something as complicated as DCOM or CORBA if you were really bored.

But it's still nothing more than winging JavaScript source code around the internet, and validating it somehow [regexp] if you don't trust its contents.

See http://www.json.org/js.html

If you're using JSON, you're using eval(). Sure, there are some workarounds that avoid calling the eval() function directly, but in the end, they all eval-uate remote code.

JSON parsers use eval() after checking the JSON string to make sure it's actually a JSON string.

cat http://www.json.org/json2.js | grep eval(

how about removing 70% of the code which just encodes/decodes from XML

{
name: "Jenny",
phone: "867-5309"
}

And let's ignore the fact that AJAX really doesn't work without XML, will we? Because that kind of defeats the original whiney argument.

I agree with most of what you wrote, but this assertion is just incorrect. Plenty of "AJAX" systems use non-XML formats to ship data around. One obvious alternative is JSON, but others exist too.

(Unless you're talking about "AJAX using XML" in the sense of "AJAX manipulating the DOM", but that's not really accurate either, since most sites don't provide well-formed XML as output and they still use AJAX techniques just fine.)

This is what I mean: http://www.json.org/JSONRequest.html

Using a less difficult markup... JSON.

Before you flog yourself too much with XML, check out JSON: http://www.json.org/.

It's supported by every language under the sun, and really simple to use. You may end up needing the extra capabilities of XML, but if you don't JSON is a much friendlier experience.

This is sad. As a programming language, Javascript makes Visual Basic look good.

How is that? Javascript is a pretty good duck typed prototype-based language. The syntax is similar to c++, but being interpreted you have awesome RPC features built in eg. JSON. I don't get how you could even compare the two.

He doesn't say "XML is S-expressions" (though the main arguer to the contrary skips around a lot without actually refuting the proposition), he says "JSON is S-expressions". If you spend about 45 seconds reading Introducing JSON, sure enough, JSON is S-expressions.

XML is now so last week. Really l33t web apps use JSON, which is yet another way to write S-expressions like those of LISP, but now in Javascript brackets.

There are several security problems with JSON. First, some web apps parse JSON notation by feeding it into JavaScript's "eval". Now that was dumb. Some JSON support code "filters" the incoming data before the EVAL, but the most popular implementation missed filtering something and left a hole. Second, there's an attack similar to the ones involving redefining XMLHttpRequest: redefining the Array constructor. (Caution, page contains proof of concept exploit.)

The real problem is JavaScript's excessive dynamism. Because you can redefine objects in one script and have that affect another script from a different source, the language is fundamentally vulnerable. It's not clear how to allow "mashups" and prevent this. The last attempt to fix this problem involved adding restrictions to XMLHttpRequest, but that only plugged some of the holes.

As a minimum, it's probably desirable to insist in the browser that, on secure pages, all Javascript and data must come from the main page of the domain. No "mashups" with secure pages.

PHP 5.2.x includes standard json encode/decoding (if you don't mind the limitations). For earlier versions, json.org lists 6 ways to do it, most of which require recompiling.

eval('(' + json + ')'). There are libraries if you don't trust your source:

http://www.json.org/js.html

is one.

This is the most pointless article I've seen linked from slashdot in a long time (and yes, I've seen a lot of crap here). What is the point of posting a run of the mill tutorial on something that's been covered many times before?

Having spent a lot of time playing with this crap lately, can I just butt into this pointless thread and say screw XML, use YAML or JSON instead. XML is a steaming, clumsy overrated turd. I benchmarked XML::Simple against YAML::Syck - the latter encoded 2.5 times faster and parsed nine times faster than XML::Simple. The syck library is indeed aptly named.

"Leverage the power of XML" by deprecating it wherever you can for a more sensible cross platform format.

</rant>

If the thought of object-oriented XML makes you whimper, check out JSON - the fat-free alternative. It's object-oriented, with most (though not all) of the benefits of XML, lightweight, and simple.

There's a lot more to object orientation than simulating a vtable with an associative array. How can you have encapsulation without persistence or visibility modifiers?

Most of the dynamic language evangelists claim that the ability to add or modify methods at run time is a good thing. I believe this to be the part that takes getting used to. I can see the value of adding or modifying methods but feel that this should be done declaratively (e.g. Ruby or .NET 2) instead of by manipulating the associative array directly in code. I am okay with aspects and method interception even though some implementations use a dynamic approach. The developer experience is still declarative.

I agree that the DOM and browser disparities are an issue, however, those issues are mitigated by modern libraries such as prototype.

One big advantage to java scipt's associative array is an object approach is that is what allows JSON to work. JSON is a very easy way to serialize in arbitrarily complex object hierarchies into java script which is a good thing for complex AJAX apps. The down side to this approach is increased exposure to man-in-the-middle attacks that can run arbitrary code client side.

Wrong, you do not need to know XML. I write "AJAX" applications at work all the time and haven't used XML for months. Look up JSON and make your life better.

Remember that with XMLHTTPRequest you are restricted to your own domain, so more often than not you are in charge of the message encapsulation language. You only have to make it as complicated as you want to.

On a slightly weaker note, some people are lucky enough to drop CSS from that list as well. Frequently I work with a designer who takes care of all the CSS for me - all I deal in is IDs and classes.

At the ajax experience Brendan Eich spoke about this and without mentioning company names. The boost in performance in JS will cement web application's future and will bring javascript to the forefront even more as the power language that it is. Combine that with JSON and the module tag proposal, it should be some very interesting times.

At the ajax experience Brendan Eich spoke about this and without mentioning company names. The boost in performance in JS will cement web application's future and will bring javascript to the forefront even more as the power language that it is. Combine that with JSON and the module tag proposal, it should be some very interesting times.

Browser vendors are aware of the problem, they don't add HTTP headers without a good reason. Common sense may be in low supply, seems there's just enough to stop web devs from setting 20 4KB cookies. The issue with AJAX (which rarely uses XML BTW) is that it's a dirty hack on top of HTTP. When all you have is a hammer...

http://www.json.org/license.html

Relevant sentence: "The Software shall be used for Good, not Evil."

>Easier to use XML rather than key/value pairs? ;)))) Dude, Javascript Arrays can be loaded with a single string

And, there's always JSON if you don't feel like hand-wrangling all those value pairs.

So, you want to represent data, heh?
Here are three choices I've gotten to work:
JSON
XML
CSV
Have you ever seen nested CSV files? They're truely bizzare to see, but if you have a sufficiently powerful parser, they can be read. New Line characters are to be record separators only when they are fully outside of quotes. Commas are to be used as field separators, only when they are fully outside of quotes. Quotes are to be used as content descriminators only when not doubled up.
The closest thing to a CSV spec that I've ever found.
My silver bullets of choice? Data encoding for transfer.
My next favorite silver bullet set, Web Services.
My other favorite silver bullet set, Programming Languages.

IMarv

It reuses existing technologies instead of re-creating new ones. Javascript is very quick, depending on what you're doing. We're loading about 8k XML Object's in Javascript and it's only as slow as your bandwidth.

It uses CSS for style(look&feel), so your web guy can do it, or you can if you're familiar with it.

It has translation support built in if you wish to use it, nothing requires you to use it but using it is automatic, nothing to enable, no 3rd party libraries to include.

XUL itself(the XML UI files) are short, terse, and very easy to keep organized if you keep it split up with overlays(instead of a single file, which all languages have problems with).

It has a plugin interface built in. It's quick and easy to do a UI with it, if you know Javascript you're off pretty quickly, if you don't it's easy to pick up(until you get to the harder stuff). JavaScript is a real language, with Objects, Inheritance, Closures, a Garbage Collector, etc...

Hell, it runs Firefox and Thunderbird. AIM Triton is the same idea, different implementation(Boxely).

Making drastic changes to the UI is 10 minutes if you're just moving stuff around, sometimes less, rarely more. You can add themes to your app(Custom Branding for Clients? Not a problem, it's already built in). Again, translation is very little extra work. Client/Server is incredibly simple because of both JSON and E4X. We've got our app with a PHP backend and connecting them together is the simplest thing to do. Don't have to load up any extra libraries because you're dealing with XML, or any extra because you've got to work with XML-RPC.

JavaScript dev is much faster than C++ dev. If you need C++ dev, then you're at the wrong toolkit, although you can always XPCOM it.

I think you're questioning it as the end-all-be-all which it is not. It has it's problems, no comments in the xml code, although it's very straightforward and needing it is questionable. JavaScript and CSS comments are all there. Network connectivity is already finished for you. But it has it's problems, it's not the end all be all, but dev time is very quick, although it does have that lag when you're booting up a java app, but only 1/4 the time.

This comment will only be relevant if I guessed your intent from your problem definition.

When you say you are using Ajax to lighten your DB load, it implies might be using Ajax to request content from other servers than the source server your content comes from (cross-site scripting).

If that is the case, you can certainly expect your clients' antivirus systems to (rightfully) give you a headache.

You simply should not be doing that, and until something like http://json.org/JSONRequestJSONRequest (proposed for inclusion into ECMASCript core)is implemented in Ajax in an acceptable, core way, then you should stay far away from cross-site functionality. Go through a proxying solution to handle off-site content vian agents on your server.

JavaScript's lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile.

Always validate what you run through eval()!

While not fool proof, making sure that what you got back from the server is JSON, and not a string of malicious code is paramount.

And guess what, such things already exist.

Granted, this doesn't prevent someone from embedding that same malicious code in valid object code that appears identical to what you expect as a server result, but its a huge step in the right direction.

Additionally, the X in AJAX doesn't really belong - if you run a protocol analyzer, you'll find XMLHTTPRequest doesn't actually send XML at all unless you explicitly send some XML.

Using JSON, JavaScript can load data from any address, when XMLHttpRequest requires you to stay in the same domain. Besides, JSON is JavaScript native and is therefore much easier to consume, for example, using MochiKit. As for the generator, it is trivial to convert native data to JSON data in a wide range of programming languages, including all the major server side scripting languages, like Python and Java. Yahoo has released a lot of their APIs on JSON and some excellent Python WebApp Framework has built-in support to speak to the client scripts in JSON.

Using JSON, JavaScript can load data from any address, when XMLHttpRequest requires you to stay in the same domain. Besides, JSON is JavaScript native and is therefore much easier to consume, for example, using MochiKit. As for the generator, it is trivial to convert native data to JSON data in a wide range of programming languages, including all the major server side scripting languages, like Python and Java. Yahoo has released a lot of their APIs on JSON and some excellent Python WebApp Framework has built-in support to speak to the client scripts in JSON.

That was interesting. Thanks for the link. It looks like yahoo is using JSON for their wire protocol. I find that to be interesting for two reasons. The first is that it is not an XML based protocol. The second reason is that JSON is also the wire protocol for the ironically named AJAX.NET.

I wonder who else is developing JSON based APIs and if that is going to be the next big thing?

Use AJAX without the X. JSON works quite well when XML is overkill. Sometimes you will need the complexity of XML, but much of the time(including those examples in that article), XML is complete overkill.

Use something like libhttpd or thttp to embed a webserver. Using ideas based on REST, design a RPC system (can use XML-RPC or if you're bent on making it a web based frontend, then maybe JSON-RPC) to communicate with the GUI.

So now I'm using A Caching XmlHttpRequest Wrapper with something that can be easily done in javascript: Splitting a string into an array. In my callback, I use something like

r = result.status;
if (r == Http.Status.OK)
{ arr=result.responseText.split(","); }

For me (I am the author of japano, an MVC/JSP engine also containing dynamic javascript integration features), the following additional principles are were important:

• Usability first. Don't use AJAX without a decent fallback. Don't use AJAX just because you can. Use semantic, standard-conform HTML/CSS layouts.
• Use JSON instead of XML
• Keep it simple. No object brokering or other fancy things. JSON transports data. Javascript requests and browser requests uses the same mechanisms.
• Integrate. AJAX has quite some complexity overhead. Try to minimize that complexity by offering framework assistance. Japano offers two different AJAX mechanisms. Javascript views, and Partial updates.

Why? Less verbose (easier on bandwidth) and no parsing (ever tried parsing XML using XmlHttpRequest? It sucks). JSON is object syntax. It is a real, live object serialized to string.

It just so happens that JSON is also legal Python object notation.

Hmmm... GMail, Google Maps, Google Suggest... none of these use XML. Google is also renowned for using Python. JSON syntax is the same in client-side javascript and server-side python... hmmm... makes me think twice, anyway, instead of drinking the web services kool-aid Sun and Microsoft are serving.

One of the great things about "AJAX" is that the "X" is optional. No reason to do XML at all unless that's what you want. So, if XML is overkill for your application, take a look at JSON, http://www.json.org/

I think it's better than CSV even. And it's got bindings to tons of languages, not just Javascript. So producing the server-side is also very easy.

Set your content type to "text/javascript" and you can send data over the network and have it be perfectly legal and ready to use. NO XML PARSING!

JSON (JSON.org) just happens to be legal Python syntax... which makes me think...

hmmm.... Google has a huge server farm and is renowed for using Python... Google Maps talks client/server using Javascript, not xml... Python and Javascript shared JSON sytax for serializing objects... hmmm...

It is a very efficient combo: Python, Javascript, JSON, mod_python.

See www.json.org I use this everywhere. (Althoug I use a silghtly dirrerent version 'ron' ruby object notation.

Rather than having to parse the string on the client side, have you thought of using JavaScript Object Notation when returning values from the server...JS treats them as objects right away. It's sorta like XML for JavaScript, and has been a standard part of ECMAScript long enough that all browsers support it just fine.

JSON - JavaScript Object Notation
http://www.json.org/

Enjoy! /RS