Re: [json] Re: Universal Binary JSON Specification
- On Wed, Sep 21, 2011 at 3:58 PM, rkalla123 <rkalla@...> wrote:
> **i've been using doubles for that purpose in that particular JS engine (v8).
> The Chrome team suggests treating it like two int32s:
> server-provided byte stream which I anticipate meaning that this binaryThe "new" JS version (don't remember the version number) fills that gap. It
> format doesn't benefit users in the server-to-Browser communication workflow
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 specSure, just as long as it's clear that this must be a "should" part of the
> in a relatively safe position as the primary use case will be between
> languages that support 64-bit ints.
spec instead of a "must" because not all platforms can guaranty 64-bit int
Said another way, I certainly see your point, but I am trying to avoid a
> "cut off nose despite your face" situation with forward-thinkingi agree, but just be aware that JSON itself does NOT specify ANY precision
> eventually give us 64-bit integers as the JS spec advances.
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
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
[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 +-