Re: Universal Binary JSON Specification
It reminds me of our conversation earlier about 64-bit. As you mentioned, Don has a great point, but the uniqueness of the data structure (I doubt the majority of people using JSON would use it) combined with my gut telling me to wait, I think I am going to specify BigInt/BigDecimal support in the official specification under a new section "Pending" and wait for feedback from more people.
I am working hard to keep the spec so conceptually simple that it just fits in a tiny brain-pocket any time someone reads it and they feel empowered immediately to start getting work done.
This might mean at the beginning some fringe items not being addressed, but I'd rather add them under strong demand later, then add them now and make those extra 10% of features suddenly make the format seem JUST complex enough that someone skimming it, hoping for something simple to use starts to glaze their eyes over and not be interested anymore.
I really appreciate this dialog on the subject guys, it helps get all the aspects out on the table early!
--- In firstname.lastname@example.org, Stephan Beal <sgbeal@...> wrote:
> On Thu, Sep 22, 2011 at 4:50 AM, rkalla123 <rkalla@...> wrote:
> > **
> > bigdouble - marker 'W'
> > [W][222 big-endian ordered bytes representing a BigDecimal]
> > Thoughts?
> Don's point is valid but it assumes that every environment has this support,
> and that's not the case. Maybe his use cases/environments have that. When
> writing generic code, however, "big numbers" don't exist.
> ----- 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 +-