41–50 of 53 posts
They should do the world a favor and include a datetime type.
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.
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 th…
Why? I can see the advantages of either one, but I don't see what having both gets you.
In my experience the implementation advantages of having length-prefixed lists disappear if you have to support indefinite lengths anyway.
At least it doesn't copy the JSON's braindead idea to rule out NaNs and Infs...
Wait, what? I hadn't heard about that. Whatfuck?
In short, this is because JS does not treat NaN and Infinity as numerical constants but as pre-defined, mutable variables; this way backward-compatible parsing of hypothetical sane JSON with eval would be vulnerable to injection. Nevertheless, many JSON codecs have their own idea what to do with it, so this stuff can get really nasty.
RFCs don't amount to much without adoption. The RFC database is full of protocols with grand designs and seemingly broad applicability. Look at the "Extensible Provisioning Protocol", EPP - http://tools.ietf.org/html/rfc5730 - a protocol "for the provisioning and management of objects stored in a shared central repository." - it reads as a marvelously generic protocol for client-managed key-value data storage - maybe…
-a lot of the time, a dearth of implementations of a new Thing is not because the new Thing is bad, but simply because people are change-averse and lazy, even in the face of an objectively better Thing, and
-I still consider this a quality submission; even if CBOR doesn't get adopted it's still neat to read. It's like watching one's government draft new legislation, except more relevant.
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.)
These kind of binary formats always have vulnerabilities. eg http://technet.microsoft.com/en-us/security/bulletin/ms04-00...
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 th…
> In particular I'm delighted to see both the definite and indefinite streams of things. Why? I can see the advantages of either one, but I don't see what having both gets you. In my experience the implementation advantages of having length-prefixed lists disappear if you have to support indefinite lengths anyway.
- Passing small messages around
- Doing streaming of large content (occasionally)
I'm probably doing these over different pipes, but the data shares a lot of the same characteristics and I don't want to use two totally different APIs to get the job done.
"Large" can be "I need to transfer something on the order of megabytes using a 4K intermediate buffer."
Earlier quoted context omitted.
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.
Can anyone enlighten me on why number equivalency is a good idea? The spec says that even if you're expecting an integer like 0, encoders can decide to use floating point, and things should just work. One of the first statements is that "7" should be able to be represented in multiple ways. That doesn't seem concise.
Of course, in real-world implementations, the encoder and the decoder will have a shared view of what should be in a CBOR data item. For example, an agreed-to format might be "the item is an array whose first value is a UTF-8 string, second value is an integer, and subsequent values are zero or more floating-point numbers" or "the item is a map that has byte strings for keys and contains at least one pair whose key is 0xab01".
7 is 7 whether it's uint_8 or uint_32, right?