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

Re: [json] Re: Universal Binary JSON Specification

Expand Messages
  • Dennis Gearon
    I have felt for a LOOOOOONG time, that representing numbers, including drive sizes, integers, any others, could have been future proofed and more simple using
    Message 1 of 76 , Sep 24, 2011
    • 0 Attachment
      I have felt for a LOOOOOONG time, that representing numbers, including drive
      sizes, integers, any others, could have been future proofed and more simple
      using the 'type byte' ,'num bytes byte', 'data' pattern.

      So applaud that.

      But what is the purpose of binary JSON? faster transmission, smaller memory foot
      print? Doesn't the second one get taken care of by creating the JSON object from
      the test of a JSON object?

      Let me know :-)

      Dennis Gearon


      Signature Warning
      ----------------
      It is always a good idea to learn from your own mistakes. It is usually a better
      idea to learn from others’ mistakes, so you do not have to make them yourself.
      from 'http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036'


      EARTH has a Right To Life,
      otherwise we all die.




      ________________________________
      From: rkalla123 <rkalla@...>
      To: json@yahoogroups.com
      Sent: Sat, September 24, 2011 10:52:01 AM
      Subject: [json] Re: Universal Binary JSON Specification


      Hey Dennis,

      Here is where we are:

      I have been working on a Universal Binary JSON specification and asked the group
      for feedback on it. You can check the spec here, it isn't too long:
      https://docs.google.com/document/d/12SimAfBVcl8Fd-lr_SSBkM5B_PyEhDRfhgu1Lzvfpfw/edit?hl=en_US


      I am in the midst of formalizing it to the main site here:
      http://ubjson.org/

      The reason for (another, hopefully final) binary JSON format is:
      1. To strictly adhere to the original JSON spec, introducing no
      incompatibilities or binary-only data structures that could lead to
      incompatibilities (BSON, BJSON).
      2. To strictly follow the core "Ease of use" tenant of JSON. This means more
      verbosity than something like Smile, but dead-simple, singular data structure to
      parse and understand.

      The struct looks like this:
      [type, 1-byte char]([length/count, 4-byte int])([binary data])

      My goal is that you can understand the spec in under 10mins. I see this as a
      fundamental requirement of the spec.

      In the specification, I took the JavaScript "Number" data type, and broke it
      down into 4 sub-types that I found mapped the most immediately to discrete data
      types in most of the popular programming languages I checked specs on.

      Namely:
      * byte, 1-byte
      * int32, 4-byte
      * int64, 8-byte
      * double, 8-byte

      In most of the languages I checked, these had native representations and
      optimized performance characteristics because of the support in the platform
      (e.g. C#, Java, etc.)

      I think for the most part everyone has been OK up to this point, the discussion
      that spawned more discussion was the support for arbitrarily long Integers and
      Decimals numbers.

      Specifying the format is easy enough (marker followed by length of bytes
      followed by the bytes, big-endian), but a few folks (myself included) feel that
      the requirement of arbitrarily long numbers for most developers is likely in the
      minority at the cost of adding 2 new data constructs to the specification that
      *don't* have a functional representation in every language (although it does in
      most).

      My feeling is that adding this complexity, however small, might make the spec
      just that much harder to understand in under 10mins or that much harder to write
      a parser/generator for that it could stymie adoption and usability.

      Keeping in mind that JSON's support for arbitrarily long numbers is undefined
      and depends on the parser and language you are using already, so I saw no reason
      to try and diverge by addressing this specifically in the binary spec if it had
      no ancillary in the JSON spec. People using the binary spec can work around this
      by string-encoding their long numbers, but I appreciate that is a sub-optimal
      approach for a lot of folks.

      And that is the recap of where we are. Look forward to your feedback!

      Best,
      Riyad

      --- In json@yahoogroups.com, Dennis Gearon <gearond@...> wrote:
      >
      > this subject in this mail list generated more email in one week that the list
      > had in 6 months.
      >
      > I therefore stepped back, too much to follow.
      >
      > Anyone willing to send me a summary of what has gone on?
      >
      > Dennis Gearon




      [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.