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

Re: [json] Re: Universal Binary JSON Specification

Expand Messages
  • Stephan Beal
    ... i ve been using doubles for that purpose in that particular JS engine (v8). I found no way to deserialize JavaScript objects directly from a ... The new
    Message 1 of 76 , Sep 21, 2011
    • 0 Attachment
      On Wed, Sep 21, 2011 at 3:58 PM, rkalla123 <rkalla@...> wrote:

      > **
      >
      > The Chrome team suggests treating it like two int32s:
      > http://code.google.com/p/v8/issues/detail?id=1339
      >

      i've been using doubles for that purpose in that particular JS engine (v8).

      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
      >
      The "new" JS version (don't remember the version number) fills that gap. It
      allows us to efficiently consume and produce binary data in JS. Trying to
      use a JS Array to store binary data (e.g. as 1-4 bytes/element) has a HUGE
      overhead because of the internal impl details of the Array class, which is
      normally a linked list).


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

      Sure, just as long as it's clear that this must be a "should" part of the
      spec instead of a "must" because not all platforms can guaranty 64-bit int
      handling.

      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 agree, but just be aware that JSON itself does NOT specify ANY precision
      requirements, probably because it cannot safely due so without also
      inherently excluding a range of environments. That said... since you're
      talking about encoding them, the limits of JSON do not apply to what you
      encode, as long as the encoded data is JSON-compliant (which it obviously
      is).

      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.
      >
      i sympathize entirely with that.

      --
      ----- 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 +-
      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.