Loading ...
Sorry, an error occurred while loading the content.

Re: [json] Re: Universal Binary JSON Specification

Expand Messages
  • Patrick Maupin
    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
    Message 1 of 76 , Sep 23, 2011
    • 0 Attachment
      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.
      JSON != JavaScript

      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
      the format.

      Thanks and best regards,
      Patrick Maupin

      On Thu, Sep 22, 2011 at 8:43 AM, rkalla123 <rkalla@...> wrote:
      >
      >
      >
      > Stephan,
      >
      > 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!
    • Tatu Saloranta
      ... For what it is worth, I also consider support for only signed values a good thing. -+ Tatu +-
      Message 76 of 76 , Feb 20, 2012
      • 0 Attachment
        On Mon, Feb 20, 2012 at 9:42 AM, rkalla123 <rkalla@...> wrote:
        > Stephan,
        >
        > 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.

        For what it is worth, I also consider support for only signed values a
        good thing.

        -+ Tatu +-
      Your message has been successfully submitted and would be delivered to recipients shortly.