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

Re: [json] Re: Universal Binary JSON Specification

Expand Messages
  • Mark Joseph
    I think all of this binary JSON work is great. But can you guys move it to another group. The fact is that binary JSON is not JSON. I joined this group
    Message 1 of 76 , Sep 28, 2011
    • 0 Attachment
      I think all of this binary JSON work is great. But can you guys move it to another group. The fact is that binary JSON is not JSON. I joined this group to work on JSON issues not on some new binary protocol which is not JSON. It is not fair to the group to added discussions that really belong elsewhere.

      Best,

      Mark Joseph, Ph.D.
      President
      P6R, Inc
      408-205-0361
      mark@...
      Skype: markjoseph_sc
      _____

      From: Don Owens [mailto:don@...]
      To: json@yahoogroups.com
      Sent: Wed, 28 Sep 2011 09:55:28 -0700
      Subject: Re: [json] Re: Universal Binary JSON Specification






      I like this. It meets Riyad's goal of keeping the spec simple, while
      compact in most cases, and, at the same time, meeting the need for lossless
      round trip encoding. I see it's been added to the spec. Thanks Riyad!

      ./don

      On Sat, Sep 24, 2011 at 11:59 AM, rkalla123 <rkalla@...> wrote:

      > **
      >
      >
      > John, I really like the idea and agree that 'H' is bigger and avoids
      > confusion with the smaller numeric types.
      >
      > I'll add it to the spec!
      >
      >
      > --- In json@yahoogroups.com, John Cowan <cowan@...> wrote:
      > >
      > > rkalla123 scripsit:
      > >
      > > > marker: N
      > >
      > > H for Huge might be good. We want people to encode ordinary numbers
      > > using the byte/int/double formats.
      > >
      > > > length: required example: [N][0][0][0][121][121-bytes representing a
      > > > UTF-8 string of my number]
      > >
      > > Yes. Of course, in this context UTF-8 and ASCII are the same thing.
      > > You could save some space by using a 4-bit encoding (as proposed by
      > > another poster), but that wouldn't be simple, as most languages don't
      > > support that format, and those that do (like Cobol) don't usually allow
      > > more than 18 digits of precision.
      > >
      > > > 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.
      > >
      > > Right, or even a high-precision float like
      > > 1.234571234809712348097123409871234098712340987E100000000000.
      > >
      > > --
      > > MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE
      > WUGGUMS
      > > John Cowan cowan@... http://www.ccil.org/~cowan
      > >
      >
      >
      >

      --
      Don Owens
      don@...

      [Non-text portions of this message have been removed]




      [Non-text portions of this message have been removed]
    • 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.