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

Re: [json] Universal Binary JSON Specification

Expand Messages
  • Tatu Saloranta
    ... Correct, format does not aim for minimal complexity of implementations. But for space efficiency it is pretty much a requirement as small set of names is
    Message 1 of 76 , Sep 21, 2011
    • 0 Attachment
      On Wed, Sep 21, 2011 at 10:44 AM, Stephan Beal <sgbeal@...> wrote:
      > On Wed, Sep 21, 2011 at 6:45 PM, Tatu Saloranta <tsaloranta@...>wrote:
      >
      >> **
      >> You might be interested in an existing such specification called
      >> Smile: http://wiki.fasterxml.com/SmileFormatSpec
      >> which was specified about a year ago, has Java and C implementations,
      >> and used by a few projects/products like ElasticSearch.
      >>
      >
      > Thank you for that. Smile's requirement that impls be capable of supporting
      > "shared strings" seems a bit draconian to me, though. That adds non-trivial
      > parser/writer infrastructure which would otherwise not be required
      > (especially in C, which doesn't have standard containers we can use to store
      > such strings/references in).

      Correct, format does not aim for minimal complexity of implementations.
      But for space efficiency it is pretty much a requirement as small set
      of names is typically reused over and over again for data streams, and
      back reference use can reduce size significantly.
      This is an optional feature for encoder for what it is worth.

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