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

Looking for Maintainers #179

Open
pyfisch opened this issue Feb 1, 2020 · 13 comments
Open

Looking for Maintainers #179

pyfisch opened this issue Feb 1, 2020 · 13 comments

Comments

@pyfisch
Copy link
Owner

@pyfisch pyfisch commented Feb 1, 2020

Hi everyone,

when I started the serde_cbor crate in September 2015 it was a quick experiment on how to implement a new data format in serde. In the years since then the crate was much improved and it now appears to be used in quite a few projects.

I'd like to thank all contributors including @chrysn (no-std and IO reader), @sfackler (a near complete rewrite in 2017 and several other changes), @baloo, @wildarch (no-std support), @rklaehn (tags) and many more. In this time I have been the person who replied to many issues, did small fixes and reviewed most pull requests.

The crate has a bunch of build flags (cargo features) including std, alloc (like std but without io) and tags. CBOR documents can both be (de-)serialized using Read/Write and slices/Vec<u8>. At run-time the user can choose between legacy-enums or standard serde enum and packed encoding in addition to the options offered by serde. Many issues discovered by users were due to a bad interaction between multiple features. Changes to the crate sometimes resulted in problems in a seemingly unrelated location. Within the past year it became increasingly clear to me that I don't understand all the details and interactions of different features. This is in part because I accepted pull requests implementing new features but did not review the code thoroughly enough. Some people expect me to add new features they need for their own project. If I reject these features because they complicate the crate and I don't want to maintain them they are unhappy.

I currently don't use CBOR in any project and therefore I maintained the crate mainly as a service to the Rust community. As serialization is not very exciting I kind of lost interest and often people need to wait a long time before I reply to their issues or pull requests.

For these reasons I decided not to continue the development of this crate and only occasionally review pull requests with bug fixes.

Unless of course a Rustacean who wants to continue the development and maintain the crate. There appears to be demand for a good CBOR implementation in Rust but currently this crate does not fit all use cases. To make the crate more useful and bug free I believe an almost complete rewrite is necessary.

The new project should consist of two parts.
First a low-level crate that parses and writes CBOR but does not depend on serde. It should support reading all valid CBOR documents including those that contain tags and unknown simple values. Users should be able to choose all serialization details including the bit-width of integers and floats. This enables the implementation of custom serialization, validation and "canonical" encodings.
The second part is a crate implements CBOR for serde and builds on the first crate. It is similar to this crate now but it should be configuration free and just serialize every data structure provided by serde. If people need packed encodings, alternative serializations, tags they can either use attributes provided by serde, add their own serialization attributes or depend only on the low-level crate. This is because the current configuration options often cause problems as noted above.
The proposed rewrite wouldn't be backwards compatible but right now the crate is a dead-end and I don't think it can progress to 1.0 from there neither can the existing bugs all be fixed. I'll be happy to give advice on the rewrite and help with problems.

If you want to maintain the crate (or even attempt the rewrite) leave a comment.

Thanks for reading all this!

@pyfisch pyfisch pinned this issue Feb 1, 2020
@PsiACE

This comment has been minimized.

Copy link

@PsiACE PsiACE commented Feb 1, 2020

I'm interested, but I'm not a Rust expert.

@HugoReeves

This comment has been minimized.

Copy link

@HugoReeves HugoReeves commented Feb 1, 2020

Interested. I'm using serde_cbor to serialize structures into a KV store for a new project of mine.
First of all, thanks for creating this project, supporting it until now and being open about your decision to move on. So many crates become neglected without anyone noticing.
I'll take a look at the source and consider what it might take to create the new version.
Thanks again. 👍

@Stupremee

This comment has been minimized.

Copy link

@Stupremee Stupremee commented Feb 1, 2020

I’m interested as well. I always wanted to do something like this and it would be a nice challenge for me.

@Dylan-DPC

This comment has been minimized.

Copy link

@Dylan-DPC Dylan-DPC commented Feb 1, 2020

Hi @pyfisch. Thanks for the repo. If needed I can help you set up a team of people who carry forward maintaining this crate.

@vmx

This comment has been minimized.

Copy link

@vmx vmx commented Feb 4, 2020

Hi @pyfisch, thanks for all your work and the time you invested in getting tag support in and discussing related things with me.

The new project should consist of two parts.
[…]

I fully agree with your assessment. I've nothing to add.

@chrysn

This comment has been minimized.

Copy link
Contributor

@chrysn chrysn commented Feb 4, 2020

I'd be happy to take some of the workload on the first-part (CBOR serialization / deserialization), as I don't have sufficient understanding for the second (serde) -- but of course happy to collaborate with whoever would work on that.

Who'd be in for the serde part?

So how shall we go about this? Given that this crate has, so far, served so many of us well, it certainly makes a good starting point, I'd probably start off a branch that removes the serde parts and exposes the more raw (de)serialization of static CBOR primitives, using its the removed parts as guidance as to what the serde part will expect. Whom may I ping to review this at its early stages?

@Stupremee

This comment has been minimized.

Copy link

@Stupremee Stupremee commented Feb 4, 2020

I can do the serde part. I suggest to expose a struct or enum which represents any data that can be serialized and deserialized like serde_json does it with their Value enum.

@rvagg rvagg mentioned this issue Feb 5, 2020
@Erutuon

This comment has been minimized.

Copy link

@Erutuon Erutuon commented Feb 6, 2020

I suggest to expose a struct or enum which represents any data that can be serialized and deserialized like serde_json does it with their Value enum.

That's provided by serde_cbor::Value, I think.

@ajeetdsouza

This comment has been minimized.

Copy link

@ajeetdsouza ajeetdsouza commented Feb 6, 2020

I can take it up. I've written a serde crate before, so this should be pretty doable.

@jhpratt

This comment has been minimized.

Copy link

@jhpratt jhpratt commented Feb 6, 2020

I am not interested in being a full maintainer, but am willing to review code as necessary. Feel free to ping me as desired!

@wildarch

This comment has been minimized.

Copy link
Contributor

@wildarch wildarch commented Feb 6, 2020

@pickfire

This comment has been minimized.

Copy link

@pickfire pickfire commented Feb 11, 2020

I think it may be good for cbor to be under https://github.com/serde-rs/cbor? Not sure what @dtolnay thinks.

If there is a rewrite, I am also interested to help out with the serde part.

@pyfisch

This comment has been minimized.

Copy link
Owner Author

@pyfisch pyfisch commented Feb 16, 2020

Hi everyone,

there are surely more people willing to invest time in this crate than I expected. 😃

@hansl messaged me in private and offered to write both a non-serde CBOR crate, the serde integeration and maintain the crates in the future. He has written a README for the low-level API: hansl@cbb5fb5 I've already added a few remarks, maybe you want to have a look and add your comments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.