Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CBOR – A new object encoding format

grimpen.org

Post reply on HN
Print view View original

1–10 of 10 posts

Re: CBOR – A new object encoding format

#3

Post by michaelmior »

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.

Re: CBOR – A new object encoding format

#4

Post by goldenkey »

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.

Re: CBOR – A new object encoding format

#5

Post by orclev »

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.

Re: CBOR – A new object encoding format

#8

Post by unwind »

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.

Re: CBOR – A new object encoding format

#9

Post by eeadc »

orclev wrote: post #5

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 th…

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

Re: CBOR – A new object encoding format

#10

Post by eeadc »

jmspring wrote: post #7

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/
Post reply on HN