Split hyper into more crates

[habnabit]

Perhaps a duplicate of #189? Unsure of what all falls under its scope, but I'd like to be able to use more than just hyper::header separate from hyper. Here's what I pared it down to when I was trying to figure out what all I needed from hyper:

Submodule	Description
error	Error and Result module.
header	Headers container, and common header fields.
method	The HTTP request method
mime	Re-exporting the mime crate, for convenience.
status	HTTP status codes
uri	HTTP RequestUris
version	HTTP Versions enum

I ended up with a lot of 'unused function' warnings from hyper::http with the minimal set of changes. Should those be exposed in a split crate, maybe?

[seanmonstar]

With the introduction of cargo 'workspaces', this may be more feasible. My gut feeling is to make a hyper-types crate, that hyper depends on, which includes the header, method, status, uri, and version modules.

[NeoLegends]

Please split it up into more crates. People could start depending on only the things they truly need instead of importing hyper as one super big crate.

[abonander]

For example, in multipart, I'm essentially hand-rolling header parsing for the fields because I don't want to unconditionally depend on hyper and bloat the build.

[jwilm]

I'm interested in having the header, method, and status crates split out at least. These are theoretically very reusable components aside from requiring all of hyper at the moment.

[seanmonstar]

Something I've been thinking about recently was to instead make "client" and "server" features in the Cargo.toml. So, someone who only needs the client or the server can enable only that feature, and even both could be disabled if you just wanted the types.

[habnabit]

I do like that as a possible solution.

[abonander]

It would be nice to have a more complete header parsing crate out there, though.

[seanmonstar]

@abonander I'm not sure what that means. Something more than httparse? Essentially hyper::header?

[abonander]

Yeah, hyper::header separated into its own crate would be neat, then it can be reexported like normal but pub extern crate hyper_header as header or something.

I've gotten httparse to work for my use-case and the zero-copy parsing is nice, but having a whole crate of header definitions would be great too.

[seanmonstar]

If hyper were to define "client" and "server" features, then disabling them would leave the following modules:

• error
• header
• method
• status
• uri
• version

While not all strictly needed by the header module, some of it is (error, method, I can't recall if others). That would mean that there wouldn't be much more gained removing the others, for more effort, no?

[habnabit]

@seanmonstar not mime? The rest of that looks good, though.

[seanmonstar]

Oh right, I forgot about mime since it isn't in the file tree. It'd still be there, since header requires it.

[habnabit]

So, I'm not sure if it's something necessarily relevant to this issue, but it would be nice to be able to provide my own hyper client provider to a library that needs a client without having to modify the library. Neither splitting hyper nor using features would inherently solve this, I think. But, this is at least part of my motivation.

[jimmycuadra]

I just posted this on #189, but this issue seems more active:

Would there be any disadvantages to extracting the status and header modules into their own crates? What about giving them generic (non-"hyper") names? It'd be great to have generic types for these concepts in the Rust ecosystem (like we have the url crate) that could be used by downstream crates without having to tie their APIs to anything specific to Hyper.

[jimmycuadra]

Maintainers, would you please let us know what your inclination is on this? Is it something you're leaning towards doing? Or is more discussion required before you can answer that? If the plan is for this to happen, would it be possible to do as part of the 0.11 release, or would it be done after that, with 0.11 just focusing on async?

I ask because we're kind of in limbo on some decisions in one of Ruma's libraries. We're looking for a generic implementation of HTTP methods, HTTP status codes, and HTTP headers. Hyper's types for these things fit the bill perfectly, but we don't want to tie our API to Hyper as-is, with all the other things it comes with. If we know for sure that there aren't plans to split these things out from Hyper, or that they're not even really on the roadmap right now, we can plan accordingly. Thank you!

[KodrAus]

Specifically, I'd like a crate for status codes. Right now in some response APIs of mine I expose the status as a u16 because I don't have a dependency on hyper.

hypers license is permissive, so there's nothing stopping someone from doing a copy+pasta of the status mod, slap the license in there and call it a day. It's not really the same as a crate blessed by @seanmonstar though that we know will always be in line with hyper (and any other http bits a user may want to use).

[abonander]

I'd still like to advocate for separate crates, if only because it allows them to be built in parallel even in release mode.

[seanmonstar]

So, while I don't have a specific announcement to make, I can say that a few of us in the HTTP space are working on a crate that would standardize many of these types, allowing frameworks to depend on those, without having to declare a relationship with a specific server or client implementation (such as hyper).

[tshepang]

@seanmonstar is it a private project at the moment, or is there somewhere where one can join in, even if just to watch progress?