On Wed, Aug 14, 2013 at 4:23 PM, Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
wrote:
On 8/13/2013 3:20 PM, Joe Hildebrand wrote:
One of the reasons why I like the CBOR tag applied to a byte stream is
that
it can be used to skip parsing on entire sections (no matter their
underlying types) in processors that don't need to understand that
section.
This is an example of the core reason that having a "one true standard" is
not appropriate for many topics: design choices optimize along particular
axes, giving particular optimizations, typically at the expense of others.
Different operating context benefit from different optimizations.
It makes sense for a specification to document its tradeoffs; it often
does not make sense to choose only one such specification for use in all
scenarios.
Maybe, but should the standards process at least uncover what the potential
design axes might be?
I think that we could actually dispense with design options for application
protocols entirely Remember that standards are all about making design
choices that don't matter.
It does not matter how the bits are encoded on the wire, all that actually
matters is the complexity of decoding them. And CBOR is not a good encoding
by that measure. It has a lot of options and is designed to offer even
more. CBOR is retrograde to MessagePack, a step backwards.
90% of Application protocols are simple API function calls. The other 10%
are API function callbacks. Thats it.
We have a complete set of intrinsic types that are recognized by modern
programming languages. There are some programming languages that don't
recognize all the intrinsic types of C/C#/Java but at this point the
intrinsic types that are not supported those languages are pretty few and
tending to decrease rather than increase over time.
The approach I took in JSON-BCD was to start with the assumption that the
JSON data model was sufficiently complete to be considered definitive
(after adding binary arrays) and then propose three extensions to the JSON
encoding model to provide what I believe to be 100% coverage of all
reasonable use cases.
It is possible that I did not succeed but there are two ways that I might
have slipped up. Dave does not distinguish between these.
1) An application might need a richer data model than JSON affords.
2) An application might need a more efficient bit packing than JSON-BCD
provides or a canonical encoding.
I can't address the first since the starting point for my design is to not
change the JSON data model. If someone did find JSON insufficient then they
should probably be looking at XML or ASN.1 anyway.
The second is easy enough to address, just add another encoding like I did.
--
Website: http://hallambaker.com/