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

Meta: Moving forward #153

Open
4 tasks
seanmonstar opened this issue Aug 21, 2023 · 2 comments
Open
4 tasks

Meta: Moving forward #153

seanmonstar opened this issue Aug 21, 2023 · 2 comments

Comments

@seanmonstar
Copy link
Member

seanmonstar commented Aug 21, 2023

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

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.
This was referenced Aug 21, 2023
@djc
Copy link

djc commented Aug 23, 2023

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
Copy link

JonathanWoollett-Light commented Oct 8, 2024

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/.

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

No branches or pull requests

3 participants