4 ms·

How does this compare to other similar specifications, e.g. MsgPack and BSON?

Zash 11y ago
There's a comparison at the end of the specification: http://tools.ietf.org/html/rfc7049#appendix-E http://tools.ietf.org/html/rfc7049#appendix-E Having written an implementation (the Lua one) I quite like this format, it's flexible, not too complicated and still quite compact.
rspeer 11y ago
From what I've read of the spec so far: msgpack has a confusion between text and binary data baked into it that will probably never be resolved, and CBOR deliberately fixes that. It also seems to have a better implementation of streaming data than msgpack. In msgpack, streaming is something you have to implement outside of the format itself, possibly by concatenating together many msgpack representations. CBOR has a way to say "here comes a streaming list, I'll tell you when it's done". BSON is a representation of MongoDB's data model and doesn't make that much sense to use without MongoDB. I currently use msgpack for a lot of things, but if CBOR's Python library is good enough, I might switch.
- Matthias247 11y ago
  Afaik newer versions of messagepack added an extra type to have string and binary now seperated. I read somewhere that CBOR was better designed for extensibility, but don't know anything further about it. One difference (on the non-technical side) is that CBOR is standardized through IETF.
  - rspeer 11y ago
    > Afaik newer versions of messagepack added an extra type to have string and binary now seperated. The problem is that the 'str' type contains arbitrary binary data in an unspecified encoding, and always will, because of backward compatibility. This isn't changed by adding a 'bin' type. Msgpack decoders in Python, for example, have to give you bytestrings unless you pass an option that promises that 'str's are all encoded in UTF-8.
    - tracker1 11y ago
      They should just add a UTF8 type... I don't know why that wasn't the default for strings all along.
    - prutschman 11y ago
      From https://github.com/msgpack/msgpack/blob/master/spec.md https://github.com/msgpack/msgpack/blob/master/spec.md Raw String extending Raw type represents a UTF-8 string Binary extending Raw type represents a byte array
      - rspeer 11y ago
        Ah okay, I didn't know there was now a specific String type (and that the one I was calling 'str' is called 'raw'). Does the Python library use it?
        prutschman 11y ago
        It can: see https://github.com/msgpack/msgpack-python#string-and-binary-type https://github.com/msgpack/msgpack-python#string-and-binary-...
        rspeer 11y ago
        I don't even know what to believe anymore. That documentation is referring to two types, with "raw" renamed to "str" plus a new "bin", which is what I thought it was. But the link you posted referred to three types, where "str" and "bin" subclass "raw", which sounded like it provided a non-backward-compatible "str" that's guaranteed to be text.
  - spc476 11y ago
    The base types are "unsigned int", "negative int", "binary data", "UTF-8 string", an array of said items, a map (key,value) of said items, extended types (up to 2^64) and tags (again, up to 2^64). There are only 8 "extended types" currently defined (false, true, null, undefined, half float (IEEE 16b), single float (IEEE 32b) and double float (IEEE 64b) and break (used to terminate streaming data)), leaving plenty unused values for future expansion. Tags are used to apply meta information to a piece of datum. For example, you can tag a UTF-8 string as a URL or tag an array with a reference so it can be referred to elsewhere in the CBOR encoded data (an extension defined by the IETF but outside RFC-7049).
- brianolson 11y ago
  I wrote the Python CBOR implementation you get if you `pip install cbor`. Source project here: https://bitbucket.org/bodhisnarkva/cbor https://bitbucket.org/bodhisnarkva/cbor It's getting pretty extensive use at a few places I know, so I hope it's good enough!
  - rspeer 11y ago
    Good to know! I'll try it as soon as it supports Python 3.5, which I use on a couple of machines. The issues page tells me that you're working on that already.
    - brianolson 11y ago
      Fixed that last night. Good to go now.
calibraxis 11y ago
Comparisons to Fressian and Transit would be interesting too.
edwintorok 11y ago
How does it compare to UBJSON?

Zash 11y ago

There's a comparison at the end of the specification: http://tools.ietf.org/html/rfc7049#appendix-E http://tools.ietf.org/html/rfc7049#appendix-E Having written an implementation (the Lua one) I quite like this format, it's flexible, not too complicated and still quite compact.

rspeer 11y ago

From what I've read of the spec so far: msgpack has a confusion between text and binary data baked into it that will probably never be resolved, and CBOR deliberately fixes that. It also seems to have a better implementation of streaming data than msgpack. In msgpack, streaming is something you have to implement outside of the format itself, possibly by concatenating together many msgpack representations. CBOR has a way to say "here comes a streaming list, I'll tell you when it's done". BSON is a representation of MongoDB's data model and doesn't make that much sense to use without MongoDB. I currently use msgpack for a lot of things, but if CBOR's Python library is good enough, I might switch.

Matthias247 11y ago
Afaik newer versions of messagepack added an extra type to have string and binary now seperated. I read somewhere that CBOR was better designed for extensibility, but don't know anything further about it. One difference (on the non-technical side) is that CBOR is standardized through IETF.
- rspeer 11y ago
  > Afaik newer versions of messagepack added an extra type to have string and binary now seperated. The problem is that the 'str' type contains arbitrary binary data in an unspecified encoding, and always will, because of backward compatibility. This isn't changed by adding a 'bin' type. Msgpack decoders in Python, for example, have to give you bytestrings unless you pass an option that promises that 'str's are all encoded in UTF-8.
  - tracker1 11y ago
    They should just add a UTF8 type... I don't know why that wasn't the default for strings all along.
  - prutschman 11y ago
    From https://github.com/msgpack/msgpack/blob/master/spec.md https://github.com/msgpack/msgpack/blob/master/spec.md Raw String extending Raw type represents a UTF-8 string Binary extending Raw type represents a byte array
    - rspeer 11y ago
      Ah okay, I didn't know there was now a specific String type (and that the one I was calling 'str' is called 'raw'). Does the Python library use it?
      - prutschman 11y ago
        It can: see https://github.com/msgpack/msgpack-python#string-and-binary-type https://github.com/msgpack/msgpack-python#string-and-binary-...
        rspeer 11y ago
        I don't even know what to believe anymore. That documentation is referring to two types, with "raw" renamed to "str" plus a new "bin", which is what I thought it was. But the link you posted referred to three types, where "str" and "bin" subclass "raw", which sounded like it provided a non-backward-compatible "str" that's guaranteed to be text.
- spc476 11y ago
  The base types are "unsigned int", "negative int", "binary data", "UTF-8 string", an array of said items, a map (key,value) of said items, extended types (up to 2^64) and tags (again, up to 2^64). There are only 8 "extended types" currently defined (false, true, null, undefined, half float (IEEE 16b), single float (IEEE 32b) and double float (IEEE 64b) and break (used to terminate streaming data)), leaving plenty unused values for future expansion. Tags are used to apply meta information to a piece of datum. For example, you can tag a UTF-8 string as a URL or tag an array with a reference so it can be referred to elsewhere in the CBOR encoded data (an extension defined by the IETF but outside RFC-7049).
brianolson 11y ago
I wrote the Python CBOR implementation you get if you `pip install cbor`. Source project here: https://bitbucket.org/bodhisnarkva/cbor https://bitbucket.org/bodhisnarkva/cbor It's getting pretty extensive use at a few places I know, so I hope it's good enough!
- rspeer 11y ago
  Good to know! I'll try it as soon as it supports Python 3.5, which I use on a couple of machines. The issues page tells me that you're working on that already.
  - brianolson 11y ago
    Fixed that last night. Good to go now.

calibraxis 11y ago

Comparisons to Fressian and Transit would be interesting too.

edwintorok 11y ago

How does it compare to UBJSON?