Loading ...
Sorry, an error occurred while loading the content.

Re: [json] Re: Universal Binary JSON Specification

Expand Messages
  • Don Owens
    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
    Message 1 of 76 , Sep 21, 2011
    • 0 Attachment
      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:

      > **
      > 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.
      > The Chrome team suggests treating it like two int32s:
      > http://code.google.com/p/v8/issues/detail?id=1339
      > 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]
      > >

      Don Owens

      [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 +-
      Message 76 of 76 , Feb 20, 2012
      • 0 Attachment
        On Mon, Feb 20, 2012 at 9:42 AM, rkalla123 <rkalla@...> wrote:
        > 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.