Serde: Serialization format quality, stability and maintenance

[elliottslaughter]

I'm hoping that this issue can be the starting point for a discussion on issues around serialization format quality, stability and maintenance.

For me what triggered this train of thought was discovering that serde_cbor has become officially unmaintained as of July 2017. As a developer, I totally get it. I myself "maintain" some projects that probably deserve the same notice. As a user of the library, I find it slightly alarming. In my particular use case, I was really hoping to achieve long-term durability with my serialization format (that's one of the reasons I chose CBOR in the first place). Fortunately, I hadn't fully committed yet, but now I have to evaluate whether to plunge ahead anyway (committing myself to potentially needing to maintain or develop a new serializer later), or find a different format.

This is the for the format which is currently third on the list of formats at https://serde.rs/#data-formats . (Not that the list is necessarily ordered strictly by quality, but it certainly isn't ordered alphabetically, so it seems like a reasonable assumption that order does have some significance.)

Serde's architecture has the property that the specific serialization formats are decoupled from the main implementation. This is both an advantage and a disadvantage. In cases like the above, this decoupling can cause uncertainty and doubt when it is not clear the desired format will be maintained. In other cases, I have outright rejected certain formats because it just wasn't clear that the format was of the desired quality level in the first place.

I wonder if Serde's format ecosystem would benefit from something like the libz blitz, to help improve the quality of a core set of formats. I'm not sure the community actually has the manpower to do this, and as a disclaimer, I personally can't drive this myself. But it's a thought.

Failing this, perhaps it would be possible to explicitly note the level of support that various formats receive. Like Rust itself has tiers of support for various OSes and platforms, maybe there could be a notion of explicit tiers of support for certain formats. E.g. JSON could be tier-1 format. The potential downside would be making non-supported formats feel like second-class citizens, but it would at least clarify what level of effort the core maintainers put into each format (as opposed to relying purely on community effort).

Again, I'm very much hoping for this to be a discussion, and if there are other ideas for how to improve the situation, I'd love to hear them.

[dtolnay]

Thanks for opening the conversation about this. I will give it some thought. The current state of the world is:

• I maintain serde, serde_derive, and serde_json. These are stable and widely considered production quality. I am committed to keeping that reputation going forward. However, understand that this is a side project for me and I am not paid for the time that goes into it, so I prioritize accordingly against work and personal commitments. Currently new feature development is slow.

• I maintain serde_yaml but I do not hold it to the same standard as the previous three. In particular, it is currently based on an external YAML backend that is far from what I would consider production quality.

• I maintain serde-ignored which is a core part of TOML parsing in Cargo, but otherwise not widely used.

• I maintain erased-serde but it is not widely used or particularly well vetted.

• I maintain https://serde.rs and I am dedicated to keeping it a valuable resource for new and experienced Serde users to the best of my non-web-developer ability.

• I provide API guidance for Bincode but I am not involved in implementation.

• Lots of helpful people live in #serde (currently 82).

• Everything else I don't look at and know very little about, and I am not interested in changing that.