Re: [json] Re: Universal Binary JSON Specification
- What happens if you need to encode an integer larger than 64-bits?
Shouldn't there be a way to encode a large integer as a buffer with a byte
length? I don't think the JSON spec puts a limit on the size of an integer.
If there is no way to encode large integers in your spec, people will
invent their own way of doing it -- it's better to have a standard way of
doing it. I think you should just have another type, e.g., bigint, that is
something like a byte count (the way string has) and a set of bytes in
big-endian order representing the integer.
On Wed, Sep 21, 2011 at 6:58 AM, rkalla123 <rkalla@...> wrote:
> 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
> you mentioned.
> The Chrome team suggests treating it like two int32s:
> 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
> 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.
> 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 firstname.lastname@example.org, 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,
> > 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
> > be doubles on that platform.
> > In any case, i currently have a use case which will eventually require
> > 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]
[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 +-