21–30 of 53 posts
Serialization formats are like indentation styles. Dead easy to pick or invent one, nearly impossible to convince others to switch to it.
Earlier quoted context omitted.
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....
Could something like GZIP mask a lot of that repetition?
Looking at the spec though, it does allow numeric keys in maps so you could use id's and provide the definitions elsewhere.
This looks like a fairly well-designed format. My main concern is that this seems to have suddenly appeared out of nowhere and gone directly to RFC. (Presumably there was an Internet-Draft, but I have never seen anything about this before.)
They should do the world a favor and include a datetime type.
The lack of the string "UUID" in the RFC is also cause for concern.
They should do the world a favor and include a datetime type.
This CBOR format is being proposed by the VPN Consortium - presumably there's some specific VPN interoperability application they have in mind for this. In the meantime, everybody else will continue to use compressed JSON, or protocol buffers, or whatever other standards have good library support and interoperability and - crucially - adoption in their domain.
Anyone 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.
Earlier quoted context omitted.
I agree. I think CBOR trades off a bit too much efficiency of in-place data access for compactness of representation.
Isn't the whole point of binary serialization formats efficiency and ease of parsing? Otherwise you might as well use .json.gz and probably end up with smaller files anyway.