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

Re: Universal Binary JSON Specification

Expand Messages
  • rkalla123
    Patrick, Thank you for the pointer.
    Message 1 of 76 , Sep 23, 2011
      Patrick,
      Thank you for the pointer.

      --- In json@yahoogroups.com, Patrick Maupin <pmaupin@...> wrote:
      >
      > 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
        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.