Re: [json] Re: Universal Binary JSON Specification
- I have felt for a LOOOOOONG time, that representing numbers, including drive
sizes, integers, any others, could have been future proofed and more simple
using the 'type byte' ,'num bytes byte', 'data' pattern.
So applaud that.
But what is the purpose of binary JSON? faster transmission, smaller memory foot
print? Doesn't the second one get taken care of by creating the JSON object from
the test of a JSON object?
Let me know :-)
It is always a good idea to learn from your own mistakes. It is usually a better
idea to learn from others’ mistakes, so you do not have to make them yourself.
EARTH has a Right To Life,
otherwise we all die.
From: rkalla123 <rkalla@...>
Sent: Sat, September 24, 2011 10:52:01 AM
Subject: [json] Re: Universal Binary JSON Specification
Here is where we are:
I have been working on a Universal Binary JSON specification and asked the group
for feedback on it. You can check the spec here, it isn't too long:
I am in the midst of formalizing it to the main site here:
The reason for (another, hopefully final) binary JSON format is:
1. To strictly adhere to the original JSON spec, introducing no
incompatibilities or binary-only data structures that could lead to
incompatibilities (BSON, BJSON).
2. To strictly follow the core "Ease of use" tenant of JSON. This means more
verbosity than something like Smile, but dead-simple, singular data structure to
parse and understand.
The struct looks like this:
[type, 1-byte char]([length/count, 4-byte int])([binary data])
My goal is that you can understand the spec in under 10mins. I see this as a
fundamental requirement of the spec.
down into 4 sub-types that I found mapped the most immediately to discrete data
types in most of the popular programming languages I checked specs on.
* byte, 1-byte
* int32, 4-byte
* int64, 8-byte
* double, 8-byte
In most of the languages I checked, these had native representations and
optimized performance characteristics because of the support in the platform
(e.g. C#, Java, etc.)
I think for the most part everyone has been OK up to this point, the discussion
that spawned more discussion was the support for arbitrarily long Integers and
Specifying the format is easy enough (marker followed by length of bytes
followed by the bytes, big-endian), but a few folks (myself included) feel that
the requirement of arbitrarily long numbers for most developers is likely in the
minority at the cost of adding 2 new data constructs to the specification that
*don't* have a functional representation in every language (although it does in
My feeling is that adding this complexity, however small, might make the spec
just that much harder to understand in under 10mins or that much harder to write
a parser/generator for that it could stymie adoption and usability.
Keeping in mind that JSON's support for arbitrarily long numbers is undefined
and depends on the parser and language you are using already, so I saw no reason
to try and diverge by addressing this specifically in the binary spec if it had
no ancillary in the JSON spec. People using the binary spec can work around this
by string-encoding their long numbers, but I appreciate that is a sub-optimal
approach for a lot of folks.
And that is the recap of where we are. Look forward to your feedback!
--- In firstname.lastname@example.org, Dennis Gearon <gearond@...> wrote:
> this subject in this mail list generated more email in one week that the list
> had in 6 months.
> I therefore stepped back, too much to follow.
> Anyone willing to send me a summary of what has gone on?
> Dennis Gearon
[Non-text portions of this message have been removed]
- On Mon, Feb 20, 2012 at 9:42 AM, rkalla123 <rkalla@...> wrote:
> Stephan,For what it is worth, I also consider support for only signed values a
> No problem; your feedback are still very applicable and much appreciated.
> The additional view-point on the signed/unsigned issue was exactly what I was hoping for. My primary goal has always been simplicity and I know at least from the Java world, going with unsigned values would have made the impl distinctly *not* simple (and an annoying API).
> So I am glad to get some validation there that I am not alienating every other language at the cost of Java.
-+ Tatu +-