Re: [json] Re: Universal Binary JSON Specification
- I'm all for big integer support. I use it all the time (from Python).
As an aside, as others have pointed out, there are other similar
efforts around. If you really want to distinguish this one by making
it truly universal, then you really do have to support big integers.
In terms of design features, have you looked at the Python
pickle/cPickle modules? Even though the problem you are solving is
not exactly the same as the problem those solve, the problems are
quite similar, and it may be instructive to examine a data format that
solves a similar problem, and the well-tested underlying code (both
pure Python and C available) that implements readers and writers for
Thanks and best regards,
On Thu, Sep 22, 2011 at 8:43 AM, rkalla123 <rkalla@...> wrote:
> 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!
- 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 +-