RFC 7049 - Concise Binary Object Representation (CBOR)
tools.ietf.org
RFC 7049 - Concise Binary Object Representation (CBOR)
1–10 of 53 posts
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#2Anyone care to comment on where we might use such a thing? Is it already in use? And does it compare favourably with BSON?
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#3Anyone care to comment on where we might use such a thing? Is it already in use? And does it compare favourably with BSON?
It looks closer to msgpack if anything, but with actual strings and bytes.
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#4Anyone care to comment on where we might use such a thing? Is it already in use? And does it compare favourably with BSON?
In Appendix E in the spec, named "Comparison of Other Binary Formats to CBOR's Design Objectives" there are several comparisons - including BSON:
[BSON] is a data format that was developed for the storage of JSON-
like maps (JSON objects) in the MongoDB database. Its major
distinguishing feature is the capability for in-place update,
foregoing a compact representation. BSON uses a counted
representation except for map keys, which are null-byte terminated.
While BSON can be used for the representation of JSON-like objects on
the wire, its specification is dominated by the requirements of the
database application and has become somewhat baroque. The status of
how BSON extensions will be implemented remains unclear.Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#5At least it doesn't copy the JSON's braindead idea to rule out NaNs and Infs...
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#6Looks a good spec, great as a way of sending data to 'Internet Of Things' style devices where processing power and possibly bandwidth are issues.
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#7Avoiding the need for protocol version negotiation might be a useful feature in some systems, but it seems to me that the things you lose makes it really not worth it. Particularly, a protocol without atoms invariably ends up like most JSON APIs -- very 'stringly typed', somewhat poorly defined, and verbose on the wire.
Which is strange for a thing calling itself 'concise'.
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#8I would really love to see a convergence of such binary formats, I hate that choosing between Google's Protocol Buffers, Apache (Facebook) Thrift etc. forces you down a very specific path of non-interoperable libraries.
I would like to see how this compares to other formats with respect to serialised size...
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#9Serialization formats are like indentation styles. Dead easy to pick or invent one, nearly impossible to convince others to switch to it.
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#10Avoiding the need for protocol version negotiation might be a useful feature in some systems, but it seems to me that the things you lose makes it really not worth it. Particularly, a protocol without atoms invariably ends up like most JSON APIs -- very 'stringly typed', somewhat poorly defined, and verbose on the wire. Which is strange for a thing calling itself 'concise'.
It does seem an odd trade off. Having key value pairs is great for prototyping and the keys make it easier for people to interpret the messages and to write code to use them. On the other hand repeatedly sending readable key values seems a huge waste. I guess when streaming you could send a header with a map in it, but it then makes things complicated....