[coldnebo]

The core problem is definitely the support of custom types. I agree, if you refuse custom types everything gets a lot simpler.

Here's a very simple example of marshaling comparing Marshal dump and load in Ruby using YAML, vs. custom JSON marshalers: http://www.skorks.com/2010/04/serializing-and-deserializing-...

Note that the post shows a tree structure in YAML because Marshall gives it to you for free (synonymous with Java serialize behavior). But the post punts on implementing the same tree in JSON, probably because it's messy and complicated.

Nothing about that looks simple to me. For example, the JSON class label "A" has to be interpreted by something to actually instantiate an A Object. YAML is a bit better-- it at least defines that there is a Ruby class instance being marshaled -- but it doesn't help you if that class doesn't exist the same on client and server.

Pretty soon this leads to madness in production systems where the server evolves "A" (v2) among a sea of separately evolving clients "A" (v1, v1.1, v1.2). Then versioned class annotations get introduced, followed by attempts to differentiate between serializable and non-serializable fields, deep and shallow serialization, etc. etc. Pretty soon, your JSON marshaling isn't so simple anymore.

[crdoconnor]

>The core problem is definitely the support of custom types. I agree, if you refuse custom types everything gets a lot simpler.

Which makes perfect sense. If you cut everything down to bool, null, number, string, list and map you can represent anything and you get to remain language agnostic.

Dates can be encoded as strings and so can most of the other more 'awkward' types. This is additional work, but it's not that complicated and not a lot is gained anyhow by putting this stuff in the spec.

You really can't get more complicated than this anyhow, without introducing nasty security vulnerabilities.

[coldnebo]

> you can represent anything

If you represent something, you need to interpret it later... i.e. both client and server need the same interpretation in order to avoid errors.

> Dates can be encoded as strings and so can most of the other more 'awkward' types.

You say 'encoding', I say 'serialization'.

> It's not that complicated

It isn't as long as you use the same platform for encoding and decoding.

Maybe our experiences are different. I remember one time I had to unencrypt a string in Ruby that had been encrypted in Java. I thought, this will be simple, it's a standard AES encryption, I'll just stuff the string into the corresponding Ruby object and decrypt! I mean, both of these objects were implemented according to the same industry standard right? Boy was that a learning experience. :) Framing, padding and seeding was not implemented the same way -- it was left as a platform implementation detail that only someone trying to integrate across systems would ever notice.