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

RFC 7049 - Concise Binary Object Representation (CBOR)

tools.ietf.org

Post reply on HN
Print view View original

31–40 of 53 posts

Re: RFC 7049 - Concise Binary Object Representation (CBOR)

#31

Post by mwcremer »

ghoul2 wrote: post #14

There 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 think the thinking here is that the sender may not be able to compute the byte size of the object a priori. Think HTTP chunked encoding.

Re: RFC 7049 - Concise Binary Object Representation (CBOR)

#34

Post by angersock »

ghoul2 wrote: post #14

There 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'm a bit concerned about the "indefinite length" stuff for arrays, buffers, and strings.

That seems like something that's going to come back and byte us.

Re: RFC 7049 - Concise Binary Object Representation (CBOR)

#35

Post by michaelmior »

michaelmior wrote: post #16
otikik wrote: post #12

I 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.

Update: Fixed a bunch of bugs in the encoder and have a working decoder as well. Still no tagging, but you can encode/decode pretty much anything you could with a naive JSON implementation.

Re: RFC 7049 - Concise Binary Object Representation (CBOR)

#36

Post by Arelius »

angersock wrote: post #34
ghoul2 wrote: post #14

There 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'm a bit concerned about the "indefinite length" stuff for arrays, buffers, and strings. That seems like something that's going to come back and byte us.

Because we can store enough things to fill memory?

Re: RFC 7049 - Concise Binary Object Representation (CBOR)

#37

Post by jokoon »

ghoul2 wrote: post #14

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

Well just write the file type to deduce the size then.

I'm not sure I understand the problem you describe, really.

Even if there are string, just encode their lengths, or if you store a compound type, write the size when size can vary.

Re: RFC 7049 - Concise Binary Object Representation (CBOR)

#38

Post by drdaeman »

Someone wrote: post #32
roncohen wrote: post #17

They should do the world a favor and include a datetime type.

Whats terribly wrong with http://tools.ietf.org/html/rfc7049#section-2.4.1 ?

The minor issues are missing timezone and precision information.

But, most importantly, use of integers for datetime values hides type-level semantics. It's just integers and you, the end user, and not the deserializer, is responsible for handling the types.

I think it's quite inconvenient to do tons of `data["since"] = parse_datetime(data["since"])` all the time, for every model out there.

Re: RFC 7049 - Concise Binary Object Representation (CBOR)

#39

Post by angersock »

Arelius wrote: post #36
angersock wrote: post #34

Earlier quoted context omitted.

I'm a bit concerned about the "indefinite length" stuff for arrays, buffers, and strings. That seems like something that's going to come back and byte us.

Because we can store enough things to fill memory?

Name me a particular time where a file format has ever had increased robustness, speed, security, or implementation simplicity because it did not specify record size ahead of time.

Please convince me of the reliability of sentinel values and null-terminated strings.

Re: RFC 7049 - Concise Binary Object Representation (CBOR)

#40

Post by kabdib »

This gets a surprising number of things right. I've worked on a couple of these. In particular I'm delighted to see both the definite and indefinite streams of things.

I'm a little bit tired (well, more than a little tired) of standards that aren't couched in terms that are directly executable. English descriptions and psuedo-code are fine, but in the end I want to have some working code that implements an API for the stuff. Doesn't have to be an official API, but something usable shows me that (a) it is indeed usable, and (b) will go a long way towards heading off other people's mistakes.

We don't do crypto without test vectors. I don't know why we think we can do other complex standards without test vectors, either. (I worked on NBS / NIST in the 70s on some verification suites. Have we lost that practice?)

I think that much of what is busted on the modern web can be traced back to loose english and lack of reference code (even stuff with placeholders). CSS, HTML, etc., I'm looking at you... :-/

Post reply on HN