Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Expose Serializer and Deserializer as pub? #62

Open
1 task done
timClicks opened this issue Nov 20, 2022 · 3 comments
Open
1 task done

[Feature]: Expose Serializer and Deserializer as pub? #62

timClicks opened this issue Nov 20, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@timClicks
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Description

I would like to add CBOR support to a data conversion utility that I've created, which makes use of serde. To do so, I would preferably like to access Deserializer and Serializer directly, rather than through helper methods.

Acceptance Criteria

Ability to use ciborium::{Serializer, Deserializer} from other crates.

Suggestions for a technical implementation

No response

@timClicks timClicks added the enhancement New feature or request label Nov 20, 2022
@brusshamilton
Copy link

I think this is something that you really need before you claim that you have Serde support. If you don't provide a public Serializer/Deserializer struct implementing those traits it really restricts the ability to efficiently implement custom conversions on top of it (such as using the Visitor pattern with deserialize_any).

@djkoloski
Copy link

+1, ciborium is likely taking an unnecessary hit in my rust_serialization_benchmarks because it only exposes an API for ciborium_io::Read/Write types. All of the input/output buffers are available as contiguous slices, and readers and writers add significant overhead. Compare ciborium vs cbor on the log benchmark:

Crate Serialize Deserialize Size Zlib Zstd
cbor 2.2871 ms 7.6305 ms 1407835 407372 324081
ciborium 4.3776 ms 12.279 ms 1407835 407372 324081

A more efficient API surface could be free performance!

@LevitatingBusinessMan
Copy link

This is more or less a duplicate of #18

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: New
Development

No branches or pull requests

4 participants