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

Re: [json] Re: Universal Binary JSON Specification

Expand Messages
  • Tatu Saloranta
    ... I can not disagree more on understand in under 10 mins aspect. Why should that matter? Users will NOT (need to) read the spec; they will use whatever API
    Message 1 of 76 , Sep 24, 2011
      On Sat, Sep 24, 2011 at 11:23 AM, rkalla123 <rkalla@...> wrote:
      > Hmm! John, I like that idea... it is simple, singular and easy to represent.
      >
      > What would you think of something like this:
      > marker: N
      > length: required
      > example:
      > [N][0][0][0][121][121-bytes representing a UTF-8 string of my number]
      >
      > 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.
      >
      > This fits really nicely into my "understand in under 10 mins" requirement for the spec, there is no discussion about twos-compliment this, or endianness that... it is just "Here is a huge number, as a String, marked by the letter 'N' and a length... have fun!"
      >
      > Would like to know what others thought?

      I can not disagree more on "understand in under 10 mins" aspect. Why
      should that matter?
      Users will NOT (need to) read the spec; they will use whatever API
      lib/framework has. No sane developer would write their own
      parser/generator, so only one who need to understand it are library
      developers, all two dozens of them.

      This is very different from textual JSON, where representation itself
      is directly editable, and readability matters.

      Not understanding obvious differences between JSON (textual), and
      matching binary representations is a bad sign for any proposals.

      But I will leave it at that, it's a free world & good luck with the effort!

      -+ Tatu +-
    • 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.