On Thursday 30 April 2015 13:10:16 Keane, Erich wrote:
> I'm not sure that we want to customize JSON that significantly. I am
> thinking that we should currently do #1 (allow the consumers to
> use/abuse the string type to do this) which is no change.
>
>
> If we are talking about doing this much customization to the JSON, we
> should be talking seriously about just switching to a protocol that is
> better suited to our needs.
Then we should limit our data types to "JSON++":
- primitives:
boolean
null
53-bit integers
floating point
US-ASCII text strings
binary byte arrays
- heterogeneous arrays of the above, except binary
- dictionaries of US-ASCII text strings to the above
For the binary data, we'll need to base64url-encode the data so we can
transmit over JSON and we need a way to indicate that it's encoded. I don't
see a way out for this, so I recommend prepending or appending a special
character to the key, e.g.:
{"$field1":"AAEjRQo"}
This implies we can't have arrays of binary data.
Reactions?
Rationale:
* JSON is JS, so numbers are double-precision always floating point. Those can
store 53-bit integers without loss of precision
CBOR can store 65-bit signed integers without loss of precision
* JSON strings are always Unicode but require UTF-16 encoding with \uXXXX
escaping, so we limit ourselves to US-ASCII to avoid most escaping -- we'll
still need to do it for \r, \n, \t, quote (") and backslash characters
CBOR can store UTF-8 strings natively without escaping
* JSON maps are of text to JSON values, so the keys should be text too
CBOR can have maps of heterogeneous keys
* JSON does not have a binary type, so we need to invent our own
CBOR can send binary types without escaping
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
