Primary Navigation

Re: Universal Binary JSON Specification

Stephan, Great feedback, these are exactly the kind of nuances I wanted to uncover and discuss. When I dug through the language specs looking for the most

Message 1 of 76
, Sep 21, 2011

0 Attachment

Stephan,

Great feedback, these are exactly the kind of nuances I wanted to uncover and discuss.

When I dug through the language specs looking for the most well-supported numeric types before settling on the given 4, it seemed of all the ones I checked JavaScript was the only one that didn't have native int64 support as you mentioned.

I found no way to deserialize JavaScript objects directly from a server-provided byte stream which I anticipate meaning that this binary format doesn't benefit users in the server-to-Browser communication workflow (which is already highly optimized for text-based JSON) but as a general application binary interchange format. Like values stored as files on the server or processes communicating with one another.

It was my thinking that this leaves the int64 inclusion in the binary spec in a relatively safe position as the primary use case will be between languages that support 64-bit ints.

Said another way, I certainly see your point, but I am trying to avoid a "cut off nose despite your face" situation with forward-thinking enhancements to JavaScript engines in the next few years that I assume will eventually give us 64-bit integers as the JS spec advances.

I would hate then to be prompted to add 64-bit integers back to the binary spec after it has been out and in circulation for a few years.

ASIDE: If I am missing a native way to reconstitute JavaScript objects from a server-provided byte stream and using this binary format for server-browser communication is an optimized reality, please correct me. I was unable to dig up methods to do this.

--- In json@yahoogroups.com, Stephan Beal <sgbeal@...> wrote:
>
> On Wed, Sep 21, 2011 at 3:15 PM, rkalla123 <rkalla@...> wrote:
>
> > **
> >
> > The only difference from JSON being that "Number" is broken out into:
> > int32, int64 and double types for the purposes of making parsing of the
> >
>
> Keep in mind that JSON does not specify any required numeric precision, and
> some platforms cannot use int64. (JavaScript specifies 53 bits of precision,
> in case it matters.) e.g. in C89 there is no _portable_ int64 construct
> (that was introduced with C99, but lots of projects still use/require C89
> because of the very different levels of C99 support in various compilers). i
> know that Java is everyone's special baby, but some of us actually write
> JSON-consuming/producing C89 code. In the world of C++, Google's v8
> JavaScript engine doesn't support 64-bit integers: numbers >32 bits need to
> be doubles on that platform.
>
> In any case, i currently have a use case which will eventually require some
> type of binary support, and i will be reading through what you've posted.
> Thanks for sharing :).
>
> Happy Hacking!
>
>
> --
> ----- stephan beal
> http://wanderinghorse.net/home/stephan/
>
>
> [Non-text portions of this message have been removed]
>

Tatu Saloranta

... For what it is worth, I also consider support for only signed values a good thing. -+ Tatu +-

> Stephan,
>
> 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.

For what it is worth, I also consider support for only signed values a
good thing.

-+ Tatu +-

Your message has been successfully submitted and would be delivered to recipients shortly.