Re: [json] Re: Universal Binary JSON Specification
- rkalla123 scripsit:
> Keeping in mind that JSON's support for arbitrarily long numbersWell then, why not add just one more type code for "string-encoded
> is undefined and depends on the parser and language you are using
> already, so I saw no reason to try and diverge by addressing this
> specifically in the binary spec if it had no ancillary in the
> JSON spec. People using the binary spec can work around this by
> string-encoding their long numbers, but I appreciate that is a
> sub-optimal approach for a lot of folks.
number"? That way, ordinary JSON can be round-tripped with 100%
reliability. Well, if you have a string, array, or object with more
than 4G elements, it still can't be, but I think that objection is
*really* technical. The other formats allow it, but at the expense of
more processing complexity.
In fact, your real selling points are simple processing (at the expense
of some compression) and 100% JSON compatibility in actual use.
Income tax, if I may be pardoned for saying so, John Cowan
is a tax on income. --Lord Macnaghten (1901) 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 +-