Re: Last Call: <draft-bormann-cbor-04.txt> (Concise Binary Object Representation (CBOR)) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 1. I haven’t seen any particularly convincing evidence that CBOR would, in production, achieve any meaningful reductions in serialization time or deserialization time or code footprint or memory footprint.

I'm not sure relative to what you want to see that reduction.

But let me give you a real-world example.

Look at section 6.3.3 of the OMA Lightweight M2M Technical Specification.
This defines a TLV format for multiple-instance resources (whatever that means is not very relevant in this context).  This format is becoming a bit complicated because this is trying to be efficient (in the number of bytes needed).  Being designed from scratch, it also has certain functional deficiencies I don't want to go into here.

If you look closely behind the complexity created by the desire to be efficient, this is actually just a map of maps.  The CBOR representation of that is just as efficient (probably slightly more so) as the bespoke encoding specifically invented for this.  Apart from the direct gains in simplicity and efficiency, in an implementation, the CBOR code is likely to be shared and more polished than the bespoke code for this, so there are likely to be more gains in code size and performance.

Specialized binary formats like this TLV format are invented a dozen a day all over the industry.
Each of them has their own little set of unwarranted complexities, bizarre features, and little bugs waiting to explode in the face of their users.
Rationalizing some of them to a common base like CBOR will be a major win.
(Justifiably or not, JSON isn't even in the starting block for many of them.)

> 2. I think CBOR does too much; I’d discard half the features and see who uses *that*.  Well, if it doesn’t take off they can always try CBOR-lite next year.

In order to address use cases such as the above, CBOR has to have a certain amount of capabilities.
It is indeed a judgment call which capabilities should be included in the standard.
Feedback from people who want to use this in the IETF has led to a little bit of growth compared to the original proposal, but only moderately so.

Grüße, Carsten






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]