Re: Universal Binary JSON Specification
- Hmm! John, I like that idea... it is simple, singular and easy to represent.
What would you think of something like this:
[N][121-bytes representing a UTF-8 string of my number]
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.
This fits really nicely into my "understand in under 10 mins" requirement for the spec, there is no discussion about twos-compliment this, or endianness that... it is just "Here is a huge number, as a String, marked by the letter 'N' and a length... have fun!"
Would like to know what others thought?
--- In firstname.lastname@example.org, John Cowan <cowan@...> wrote:
> rkalla123 scripsit:
> > Keeping in mind that JSON's support for arbitrarily long numbers
> > 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.
> Well then, why not add just one more type code for "string-encoded
> 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 +-