On Wed, Aug 14, 2013 at 4:23 PM, Dave Crocker <dhc@xxxxxxxxxxxx> wrote:
--
Website: http://hallambaker.com/
On 8/13/2013 3:20 PM, Joe Hildebrand wrote: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.
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.
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/