Serialization formats are like indentation styles. Dead easy to pick or invent one, nearly impossible to convince others to switch to it.
Yes! For that reason, I also have my own: https://github.com/albertz/binstruct
RFC 7049 - Concise Binary Object Representation (CBOR)
11–20 of 53 posts
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#12I like it. Fighting the urge to write a parser for it in my language of choice.
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#13Avoiding 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....
Could something like GZIP mask a lot of that repetition?
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#14There is one significant problem I see:
the length field for compound types (arrays and maps) specify the length in "the number of items", not in bytes. This means while processing, If I need to skip a compound type, I actually need to process it in its entirety. Not very "small device" friendly.
In practice, I have found far more utility in knowing the byte-length of a compound field in advance than the number of items it contains. If I am interested in the field, I am anyway going to find out the number of items cause I am going to process it. If I am not interested in the field, the number of items are useless to me, but the byte-length would have come in handy.
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#15I was really starting to like capnproto.com
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#16I like it. Fighting the urge to write a parser for it in my language of choice.
I couldn't fight it off https://github.com/michaelmior/pycobr
Just got the encoder so far (without major type 6, i.e. tagging) and the code is pretty messy and possibly not 100% correct, but it's true that the amount of code required is pretty minimal.
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#17They should do the world a favor and include a datetime type.
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#18Any JSON object encoding format would greatly benefit from compression. It does not have to be complicated: even something as simple as using a dictionary array of "symbols" whose indices can be used instead of repeating string values.
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#19There is one significant problem I see: the length field for compound types (arrays and maps) specify the length in "the number of items", not in bytes. This means while processing, If I need to skip a compound type, I actually need to process it in its entirety. Not very "small device" friendly. In practice, I have found far more utility in knowing the byte-length of a compound field in advance than the number of it…
I agree. I think CBOR trades off a bit too much efficiency of in-place data access for compactness of representation.
Re: RFC 7049 - Concise Binary Object Representation (CBOR)
#20There is one significant problem I see: the length field for compound types (arrays and maps) specify the length in "the number of items", not in bytes. This means while processing, If I need to skip a compound type, I actually need to process it in its entirety. Not very "small device" friendly. In practice, I have found far more utility in knowing the byte-length of a compound field in advance than the number of it…
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.