chore: exploring CBOR, protobuf

[dckc]

refs: #3

This includes CBOR work noted earlier plus some playing around with protobuf and passables.

I don't know whether it should ever get merged.

cc @zarutian (I can't seem to request review from you).

[zarutian]

@dckc ya rang?

taking a look.

[kriskowal]

cc @gibson042 for CBOR experience.

[dckc]

oops... this should be 1 array of 2 items: the "S" tag and the string

[dckc]

likewise, this SELF_DESCRIBED should be followed by 1 array of 3 items: "E" tag, name, message.

[kriskowal]

I’ve got no CBOR experience, but I’m glad we’ve got evidence that CBOR can house O’Cap’n’s data model. I see possible directions going forward:

1. We can make the data representation layer pluggable. That would be handy for the web where JSON is king and nothing in JS will ever approach the performance of native JSON.parse.
2. It may be that @erights’s and I believe @gibson042’s Encode Passable depends upon the bytewise comparability of an acylic passable subtree in a way that would vary between Syrup, JSON, CBOR, Protobuf encoding layers (please confirm or deny!) In which case, it would make the more sense to commit to the concrete Encode Passable representation, which in turn closely resembles the spirit of Syrup (and Netstring at the message framing layer!)
3. Maybe the bytewise comparability invariants can be preserved in CBOR?

[gibson042]

Maybe the bytewise comparability invariants can be preserved in CBOR?

I believe so, because CBOR is strictly more general than JSON. It supports false/null/true and arbitrary IEEE 754 binary64 values (the finite subset of which corresponds with JavaScript-interoperable JSON numbers), and obviously also lists and dictionaries. And we could probably take advantage of some affordances that are lacking in JSON, such as arbitrarily-sized integers, undefined/±Infinity/NaN, and non-string dictionary keys. But there's a subtle gotcha as well—a CBOR text string (major type 3) is UTF-8 and therefore cannot represent all JSON strings (specifically those including unpaired surrogates such as "\uDEAD") without a higher-order encoding, although a CBOR byte string (major type 2) can do so if it is subject to interpretation as either CESU-8 or WTF-16 (with the latter probably being more convenient for sorting by JavaScript string semantics).