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

Re: [json] Re: Universal Binary JSON Specification

Expand Messages
  • Stephan Beal
    ... Hi! Is it still this doc: https://docs.google.com/document/d/12SimAfBVcl8Fd-lr_SSBkM5B_PyEhDRfhgu1Lzvfpfw/edit that one hasn t been edited since September?
    Message 1 of 76 , Feb 20, 2012
    • 0 Attachment
      On Mon, Feb 20, 2012 at 6:12 PM, rkalla123 <rkalla@...> wrote:

      > **
      >
      > Anyone else have any thoughts? Stephan, Don, Tatu, Milo?
      >

      Hi! Is it still this doc:

      https://docs.google.com/document/d/12SimAfBVcl8Fd-lr_SSBkM5B_PyEhDRfhgu1Lzvfpfw/edit

      that one hasn't been edited since September?

      A couple comments, both positive:

      > * no int64 length support, (REASON), not every platform plays nice with
      64-bit. ...
      > decode the format contents correctly. (WORKAROUND) just break
      > the data payload into an array of multiple STRING or HUGE's.

      A second workaround option is to use doubles for such cases.

      > * signed length values, (REASON), numeric types in UBJSON
      > are all signed.

      While i think it's an unfortunate limitation, i think it is the right thing
      to do for UBJSON. It used to bug the hell out of me that Google' v8 JS
      engine doesn't support unsigned numbers, but i've since gotten over it and
      just use doubles as a proxy when i _have_ to deal with large integers.

      :)

      --
      ----- stephan beal
      http://wanderinghorse.net/home/stephan/
      http://gplus.to/sgbeal


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