CBOR – A new object encoding format(grimpen.org)
grimpen.org
CBOR – A new object encoding format
http://grimpen.org/blog/4.html
9 comments
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.
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.
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).
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?
Obligatory http://xkcd.com/927/
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:
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.