Re: Universal Binary JSON Specification
- 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 email@example.com, 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
> MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS
> John Cowan cowan@... http://www.ccil.org/~cowan
- 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 +-