Collaborate with ciborium

[npmccallum]

https://github.com/enarx/ciborium/

Can we collaborate rather than building multiple CBOR stacks?

[quininer]

Of course, how do you hope to collaborate?

[npmccallum]

No idea. But I'd rather have one really good CBOR stack than multiple incomplete ones.

Was there some defect or design considerations in ciborium that lead to an alternate implementation?

[quininer]

There are two missing things in ciborium that prompted me to develop this crate

1. ciborium has not exposed the Serializer api for a long time
2. ciborium does not support zero-copy decode.

[npmccallum]

There are two missing things in ciborium that prompted me to develop this crate

1. ciborium has not exposed the Serializer api for a long time

enarx/ciborium#18

We have expressly supported exposing these. But nobody has stepped up to finish it. Would you like to?

2. ciborium does not support zero-copy decode.

We'd love to have this feature. Although one should note that not all CBOR wire values can be zero-copy decoded.

Would you be willing to contribute these features to ciborium?

[quininer]

I'm not sure how easy this is. when I tried to make ciborium support zero copy decode, I realized that it needed to be changed quite a bit. considering communication costs, I choose to implement my own library.

[npmccallum]

@quininer If this is the biggest blocker, I'm happy to help you implement it.

[tqwewe]

Looking at these benchmarks, it seems like cbor4ii turned out to be over 6x faster on average for serialization, and 2.5x faster for deserialization compared to ciborium.

These numbers are pretty substantial, I'm happy there's different alternatives in the ecosystem for some to provide better performance/benefits over others, and without cbor4ii, we'd only have ciborium which is much slower sadly.