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?

[JonathanWoollett-Light]

To be frank, do many care about matching and comparisons? My understanding is that the vast majority simply use it as a crate of constants to use instead of strings. It seems unreasonable to block PRs attempting to add new types based on a desire to completely rework the crate. If its simply a lack of maintainer ship it may be worth asking for new maintainers.

I think that honestly the only changes that matter are to maintain an update to date list.

If we want to go further we could simply parse https://www.iana.org/assignments/media-types/media-types.xhtml

I made https://docs.rs/mime2/latest/mime2/.