Extract typemap functionality to its own crate?

[jimmycuadra]

The typemap functionality used for the Extensions type seems generally useful. I'm wondering if it'd be possible to extract it into its own crate or to combine efforts with similar crates. A while back @reem created typemap for use in Iron, and @SergioBenitez created the state crate for us in Rocket. Both contain similar functionality. If someone wants a bare-bones typemap for use in their own library, it'd be nice if there was one implementation that was favored, and could be shared by the aforementioned crates.

[jimmycuadra]

Just found another one: anymap by @chris-morgan.

[carllerche]

Thanks for the thought. As you pointed out, there already are crates providing the functionality. Could you clarify the reasoning for creating a new one w/ the contents of the typemap used here?

[jimmycuadra]

It's just that a typemap seems like a generally useful data structure, and I wasn't sure why the one in http was written from scratch rather than using one of the existing crates. It seems the one in http is more minimal, so I then wondered if it would make sense for http's implementation to form the basis of the other typemap crates. That way if someone wants a basic typemap data structure, there is a more obvious choice, and if they want a higher level built on a typemap, there are other options built on the same foundation.

Maybe it wouldn't be beneficial to the http crate per say, I just saw an opportunity to codify a pattern I've seen in multiple places to a single place, which seemed like it would be a benefit to the crates.io ecosystem.

[seanmonstar]

As I originally wrote the Extensions piece, I'll add what my thinking was at the time: yes there are existing crates like typemap and anymap, but the amount of functionality they provide was a lot more than needed, and so for such a fundamental crate as http, I opted for just writing this tiny one internally.

[chris-morgan]

Splitting such things into their own crates is not, as some say, a fundamentally good thing; it’s a trade-off. For most applications, using a library like anymap or typemap will make sense, but for the fundamental HTTP library that people use, having it as an extra dependency does not seem worthwhile: it increases complexity and tends to slow down builds. I am, and have been from the start, strongly with Sean on http using its own type rather than using another one or extracting its own into a separate crate.

[jimmycuadra]

Okay, thanks for considering the idea, everyone!

[jplatte]

@seanmonstar Can this be reopened? axum has a potential use case for more extension functionality which the anymap crate would provide, which is now approaching 1.0 (there's a beta). See tokio-rs/axum#770.

[seanmonstar]

I don't think the reasons have changed. It's still preferable to not include another public dependency. If there's a specific thing need of the Extensions type, we can discuss that in a new issue.