Comment by crdoconnor
11 years ago
>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.
> 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.