tag | b287dd8462d182d5b3021f9ad30f5a84d9ff7bd8 | |
---|---|---|
tagger | The Android Open Source Project <initial-contribution@android.com> | Thu Jan 04 11:05:53 2024 -0800 |
object | aa55b4c31af3358a3bda4306ee05df9eb2127251 |
Android platform 13.0.0 release 15
commit | aa55b4c31af3358a3bda4306ee05df9eb2127251 | [log] [tgz] |
---|---|---|
author | Android Build Coastguard Worker <android-build-coastguard-worker@google.com> | Fri Mar 04 02:04:35 2022 +0000 |
committer | Android Build Coastguard Worker <android-build-coastguard-worker@google.com> | Fri Mar 04 02:04:35 2022 +0000 |
tree | 0217a0a1a2a77a2db3c68362ef741cc4ab4e6a72 | |
parent | 553150b7fa3fb6570fffdea59b7d4febfb5a62b9 [diff] | |
parent | 6f79db84a43489bb3bb7d7ea68a8d683b8c4c1de [diff] |
Snap for 8249732 from 6f79db84a43489bb3bb7d7ea68a8d683b8c4c1de to tm-release Change-Id: Ib66ef8775337f49da73fd09f8ba89ea96a2d4aca
Welcome to Ciborium!
Ciborium contains CBOR serialization and deserialization implementations for serde.
You're probably looking for de::from_reader()
and ser::into_writer()
, which are the main functions. Note that byte slices are also readers and writers and can be passed to these functions just as streams can.
For dynamic CBOR value creation/inspection, see value::Value
.
Although the CBOR specification has differing numeric widths, this is only a form of compression on the wire and is not intended to directly represent an “integer width” or “float width.” Therefore, ciborium always serializes numbers to the smallest possible lossless encoding. For example, we serialize 1u128
as a single byte (01
). Likewise, we will also freely decode that single byte into a u128
.
While there is some minor performance cost for this, there are several reasons for this choice. First, the specification seems to imply it by using a separate bit for the sign. Second, the specification requires that implementations handle leading zeroes; a liberal reading of which implies a requirement for lossless coercion. Third, dynamic languages like Python have no notion of “integer width,” making this is a practical choice for maximizing wire compatibility with those languages.
This coercion is always lossless. For floats, this implies that we only coerce to a smaller size if coercion back to the original size has the same raw bits as the original.
The ciborium project follows the Robustness Principle. Therefore, we aim to be liberal in what we accept. This implies that we aim to be wire-compatible with other implementations in decoding, but not necessarily encoding.
One notable example of this is that serde_cbor
uses fixed-width encoding of numbers and doesn't losslessly coerce. This implies that ciborium
will successfully decode serde_cbor
encodings, but the opposite may not be the case.
Other serde parsers have generally taken the route of using BTreeMap
or HashMap
to implement their encoding's underlying Map
type. This crate chooses to represent the Map
type using Vec<(Value, Value)>
instead.
This decision was made because this type preserves the order of the pairs on the wire. Further, for those that need the properties of BTreeMap
or HashMap
, you can simply collect()
the values into the respective type. This provides maximum flexibility.
The ciborium crate has the beginnings of a low-level library in the (private) basic
module. We may extend this to be more robust and expose it for application consumption once we have it in a good state. If you'd like to collaborate with us on that, please contact us. Alternatively, we might fork this code into a separate crate with no serde dependency.
The ciborium crate contains a number of internal types that implement useful serde traits. While these are not currently exposed, we might choose to expose them in the future if there is demand. Generally, this crate takes a conservative approach to exposing APIs to avoid breakage.
Packed encoding uses numerical offsets to represent structure field names and enum variant names. This can save significant space on the wire.
While the authors of this crate like packed encoding, it should generally be avoided because it can be fragile as it exposes invariants of your Rust code to remote actors. We might consider adding this in the future. If you are interested in this, please contact us.
License: Apache-2.0