Hacker News new | past | comments | ask | show | jobs | submit login
CBOR – A new object encoding format (grimpen.org)
24 points by eeadc on Dec 19, 2013 | hide | past | web | favorite | 9 comments

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.

Just take a look at the Appendix D of RFC7049, where they present reference implementations in C and Python for half-width float decoding: http://tools.ietf.org/html/rfc7049#appendix-D

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).

Inofficially CBOR was designed as a protocol base for CoRE-related protocols. CoRE stands for Constrained RESTful Environments and is an alternative for HTTP in restricted environments like micro controllers. See also https://ietf.org/wg/core/charter/

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

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact