Gah, that was almost unreadable due to the many typos and inconsistencies. First:<p><i>For example, the number 10 is encoded as 0x10.</i><p>As an example, that is <i>fantastically</i> 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.<p>Then, it contradicts the above in the table, where it claims:<p><pre><code> 10 0x0a
</code></pre>
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 <i>more</i> confused.
I have my own implementation very quickly hacked together for Python3 without tagging support. <a href="https://github.com/michaelmior/pycbor" rel="nofollow">https://github.com/michaelmior/pycbor</a><p>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. <a href="https://github.com/orclev/CBOR" rel="nofollow">https://github.com/orclev/CBOR</a><p>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.<p>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 -- <a href="https://news.ycombinator.com/item?id=6632576" rel="nofollow">https://news.ycombinator.com/item?id=6632576</a><p>Not sure why yet another binary encoding method is needed (per editor comments on the original ietf mailing list).