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

Re: Universal Binary JSON Specification

Expand Messages
  • rkalla123
    Absolutely! I couldn t thank all of you enough for the help refining the spec and help with addressing shortcomings. Draft 5 is currently up at the new home
    Message 1 of 76 , Sep 28, 2011
    • 0 Attachment
      Absolutely!

      I couldn't thank all of you enough for the help refining the spec and help with addressing shortcomings.

      Draft 5 is currently up at the new home for the spec (http://ubjson.org/) and I am actively added binary-representation examples for clarification as well as working on the Java library for the spec which is going really well (the Input/OutputStream impls are already in github if you want really low level/fast support right now).

      I also started a discussion with Tim at Cloudant about getting support for the Universal Binary JSON format directly into CouchDB 1.2 as a response format (he has added MessagePack support already), but he needs a Ruby or Erlang implementation and I know neither unfortunately.

      If anybody was wanting to jump in on an implementation in any language , feel free to email me and I can send you quick pointers that amount to probably 20-30 lines of dead simple code.

      I think the core Java format support took me an hour to write.

      -Riyad

      --- In json@yahoogroups.com, Don Owens <don@...> wrote:
      >
      > 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
    • 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.