CBOR – A new object encoding format

Gah, that was almost unreadable due to the many typos and inconsistencies. First:

For example, the number 10 is encoded as 0x10.

As an example, that is fantastically opaque. It tells me nothing sensible at all, there could just be a magic look-up table that you're assumed to know, for all I know. I can't draw any conclusions that lead me to believe that CBOR is "simple" from that example.

Then, it contradicts the above in the table, where it claims:

    10    0x0a

It also shows bit numbers numbered from 1 to 8, left to right, which is very different from how bits are typically numbered (from 0 to 7, right to left) and thus makes me even more confused.

I have my own implementation very quickly hacked together for Python3 without tagging support. https://github.com/michaelmior/pycbor

The one thing that Flynn seems to be missing is tests. Right now I run tests by parsing the examples from the RFC, so I consider the test suite pretty complete (for the features I have implemented). Glad this got posted since perhaps my test suite could be useful for Flynn.

I also have a nearly complete implementation of this in Haskell. https://github.com/orclev/CBOR

The main problem it currently faces is that the encoding/decoding support for half-width floats is currently wrong, but so long as you avoid half-width floats it works perfectly.

Eventually I want to add support for encoding indefinite lists by way of one of the streaming libraries like conduit or pipes, but before I do that I need to refactor to the code to break the Binary instances out from the types.

Magic delimiter constants for indefinite lists. Doesn't seem like a great implementation when you need hacks like that. Plus the size of individual data elements is restricted by the type/length information struct size. JSON is nice because it doesn't try to be very efficient, yet it's wholly better than XML. This is a binary format, not really comparable considering how restricted this is.

Prior thread -- https://news.ycombinator.com/item?id=6632576

Not sure why yet another binary encoding method is needed (per editor comments on the original ietf mailing list).

This is cool. Are there any numbers on how it compares size/speed on some test data structures to msgpack/json/etc?

Obligatory http://xkcd.com/927/