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

Re: [json] Re: Universal Binary JSON Specification

Expand Messages
  • Dennis Gearon
    Since this IS about JAVAscript (not really java, buuuuuuut), use the Java specification for unlimited length integers. Propose it to the javascript/emca
    Message 1 of 76 , Sep 24, 2011
    • 0 Attachment
      Since this IS about JAVAscript (not really java, buuuuuuut), use the Java
      specification for unlimited length integers. Propose it to the javascript/emca
      specification group at the same time.

      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: John Cowan <cowan@...>
      To: json@yahoogroups.com
      Sent: Sat, September 24, 2011 11:01:29 AM
      Subject: Re: [json] Re: Universal Binary JSON Specification


      rkalla123 scripsit:

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

      Well then, why not add just one more type code for "string-encoded
      number"? That way, ordinary JSON can be round-tripped with 100%
      reliability. Well, if you have a string, array, or object with more
      than 4G elements, it still can't be, but I think that objection is
      *really* technical. The other formats allow it, but at the expense of
      more processing complexity.

      In fact, your real selling points are simple processing (at the expense
      of some compression) and 100% JSON compatibility in actual use.

      --
      Income tax, if I may be pardoned for saying so, John Cowan
      is a tax on income. --Lord Macnaghten (1901) cowan@...



      [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 9:55 AM
      • 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.