Re: [json] Re: Universal Binary JSON Specification
- I like this. It meets Riyad's goal of keeping the spec simple, while
compact in most cases, and, at the same time, meeting the need for lossless
round trip encoding. I see it's been added to the spec. Thanks Riyad!
On Sat, Sep 24, 2011 at 11:59 AM, rkalla123 <rkalla@...> wrote:
> John, I really like the idea and agree that 'H' is bigger and avoids
> confusion with the smaller numeric types.
> I'll add it to the spec!
> --- In firstname.lastname@example.org, John Cowan <cowan@...> wrote:
> > rkalla123 scripsit:
> > > marker: N
> > H for Huge might be good. We want people to encode ordinary numbers
> > using the byte/int/double formats.
> > > length: required example: [N][121-bytes representing a
> > > UTF-8 string of my number]
> > Yes. Of course, in this context UTF-8 and ASCII are the same thing.
> > You could save some space by using a 4-bit encoding (as proposed by
> > another poster), but that wouldn't be simple, as most languages don't
> > support that format, and those that do (like Cobol) don't usually allow
> > more than 18 digits of precision.
> > > In this case the number could be a decimal or int value, but it would
> > > be up to the language parsing it to decide and return the right value.
> > Right, or even a high-precision float like
> > 1.234571234809712348097123409871234098712340987E100000000000.
> > --
> > MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE
> > John Cowan cowan@... http://www.ccil.org/~cowan
[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 +-