Meta: Moving forward

[seanmonstar]

This is a meta issue to collect the steps needed to move this crate forward. While it is currently "maintained", in that severe bugs will be merged, it's otherwise rotting. I'm hopeful we can revive it, but I'll need your help.

• Propose Tenets/Values #154
• Fix up master (so that it's pointing at code that matters, not a failed design)
• Propose a design based on the tenets
• Implement an accepted design proposal

Related to

• Please maintain this #135
• 1.0 Release Discussion / Wishlist #52

Previous Attempts

0.1: Mime(TopLevel::Plain, SubLevel::Text, [])

This allowed "expressive" matching like Mime(TopLevel::Text, SubLevel::Plain, _).

Cons:

• Needs several imports to construct and to match.
• The SubLevel enum contained variants that only made sense for some top-level types.
• The +suffix (application/text+xml) was conflated with the sub-level type.
• Exposed representation, so no optimizations were possible.
• A SubLevel::Other(String) is a backwards-compatibility hazard for adding new variants that used to parse as Other.

0.3: struct Mime, mime::TEXT_PLAIN constants

Still allowed matching, (mime::TEXT, mime::PLAIN).

Cons:

• Couldn't create constant Mimes
• Conflates types and ranges
• Conflates Names and Values

0.4 (never released): MediaType, MediaRange, and mime! macro.

Separated Mime into type and range. The mime! macro was meant to allow easier constant creation. It could also allow nicer syntax, such as mime!("text" / "plain"), without any extra imports.

Cons:

• Macro required exposing an "__private_dont_use" field that the macro could set. const fn has advanced that we probably could live without a macro.

[djc]

Have you reviewed other crates to check whether you (and other users) might perhaps be better offer migrating to an existing other option?