4 ms·

CBOR went to the trouble of being an IETF standard, RFC 7049. So, you know, the lovely thing about using standards!

ludocode 7y ago
CBOR also made a lot of changes to MessagePack making it far more complicated, both to use and to implement. I've talked about this on HN before so I'm repeating myself a bit but here's a short list: - CBOR has two ways of encoding maps and arrays: fixed length and variable-length. This complicates decoders, especially those that would pre-allocate arrays and maps to the proper sizes, which significantly reduces decoding performance. The CBOR spec has nothing useful to say about this; it just requires you to allocate indefinitely. - CBOR defines a canonical representation, including a key sorting order based on binary representation which is just awful. It requires multi-pass encoding which is slow, complex, error prone, and completely non-intuitive: [1,2,3] comes before 100000 which comes before [1,2,3,4]. - CBOR has more types in the core spec, ones that are extremely specific to certain applications or programming languages. It has a 16-bit float, and it has both null and undefined as separate types. - CBOR defined a system of "tags" with a huge number of extension types. These are supposed to be optional, but of course they only work if both ends support them. Some features like BigNum are well-supported in some programming languages but not others, so CBOR implementations tend to diverge in supported message types. CBOR as a standard is far worse than the "non-standard" MessagePack it purports to replace. Here's a great HN comment on it from another user (and another MessagePack library implementer) a few years back: https://news.ycombinator.com/item?id=14072598 https://news.ycombinator.com/item?id=14072598
- SlowRobotAhead 7y ago
  All those gripes are optional features. Your parser or encoder does not need to support indefinite arrays, that feature is clearly designed to be used with some practical limitations like “I don’t know how many but let’s assume less than x, and I’ll send a STOP when I’m done”. Canonical ordering is optional. Yes, a typed system that has more types, IDK what to say about that other than you don’t have to use them. And yes, tags need to be supported on both ends, just like ANY DATA that is being transferred, compare to a strict schema’ed system and I no difference except that you’re only partially required to adhere to the plan. Maybe msgpack is just objectively better because it has less features. IDK. Doesn’t matter because CBOR got an RFC and is actually popping up in places. If there was a competition, cbor won, right or wrong.

CBOR also made a lot of changes to MessagePack making it far more complicated, both to use and to implement. I've talked about this on HN before so I'm repeating myself a bit but here's a short list: - CBOR has two ways of encoding maps and arrays: fixed length and variable-length. This complicates decoders, especially those that would pre-allocate arrays and maps to the proper sizes, which significantly reduces decoding performance. The CBOR spec has nothing useful to say about this; it just requires you to allocate indefinitely. - CBOR defines a canonical representation, including a key sorting order based on binary representation which is just awful. It requires multi-pass encoding which is slow, complex, error prone, and completely non-intuitive: [1,2,3] comes before 100000 which comes before [1,2,3,4]. - CBOR has more types in the core spec, ones that are extremely specific to certain applications or programming languages. It has a 16-bit float, and it has both null and undefined as separate types. - CBOR defined a system of "tags" with a huge number of extension types. These are supposed to be optional, but of course they only work if both ends support them. Some features like BigNum are well-supported in some programming languages but not others, so CBOR implementations tend to diverge in supported message types. CBOR as a standard is far worse than the "non-standard" MessagePack it purports to replace. Here's a great HN comment on it from another user (and another MessagePack library implementer) a few years back: https://news.ycombinator.com/item?id=14072598 https://news.ycombinator.com/item?id=14072598

SlowRobotAhead 7y ago
All those gripes are optional features. Your parser or encoder does not need to support indefinite arrays, that feature is clearly designed to be used with some practical limitations like “I don’t know how many but let’s assume less than x, and I’ll send a STOP when I’m done”. Canonical ordering is optional. Yes, a typed system that has more types, IDK what to say about that other than you don’t have to use them. And yes, tags need to be supported on both ends, just like ANY DATA that is being transferred, compare to a strict schema’ed system and I no difference except that you’re only partially required to adhere to the plan. Maybe msgpack is just objectively better because it has less features. IDK. Doesn’t matter because CBOR got an RFC and is actually popping up in places. If there was a competition, cbor won, right or wrong.