Closed robjtede closed 9 months ago
How does splitting this crate up help? What parts of http
are you trying to avoid?
How does splitting this crate up help?
A crate with just primitives could reach v1.0 much more quickly, providing confidence to its users. Also would allow less frequent breaking changes for these types in the face a desire to use newer rustc features (think const panic in HeaderName::from_static) causing raised MSRVs and, therefore, a semver-incompatible release.
What parts of http are you trying to avoid?
Basically the opinionated parts.
For example, parts of HeaderMap
require the fnv
crate; which is opinionated. We've chosen aHash for our map types so we would choose not to carry this dep if possible. Same goes for Request
/Response
, we've got some optimisations around request head re-use that is just not possible with this lib so it's dead code for us.
The parts of http
we want to use are either simple or already considered best-in-class. These are the types which could benefit from a "core" approach, imo.
parts of HeaderMap require the fnv crate; which is opinionated.
The fnv crate is tiny. If anyone were motivated, we could very easily just inline it, it's less than 10 lines.
Same goes for Request/Response, we've got some optimisations around request head re-use that is just not possible with this lib so it's dead code for us.
Is it really not possible to do sufficient optimizations with Request
/Response
? When I was playing the benchmark game with hyper, I was able to reuse some pieces that made it "win" back then. I think it would be beneficial for libraries to be able to consider a single type for an http::Request
or http::Response
.
It could be interesting if we could provide trait Request
, trait Response
, and trait Headers
, but I believe the way generics work in Rust would just make it a pain for end users.
Besides that, I think the http
crate currently does its purpose well: be a small crate of just HTTP primitives. Splitting it doesn't seem to provide much value to end users, from what I have gathered.
My examples of why we chose to roll our own types don't really illustrate the point of this issue in particular.
be a small crate of just HTTP primitives
If you look at the definition of "primitive" from a lang perspective, then they are building blocks for larger structures, right? Using that, we can say:
HeaderMap
is not a primitive in the same way that a HashMap
is not a primitive;Request
and Response
are further composed of both primitives and non-primitives (request line / status line + header map);Extensions
isn't a HTTP concept at all.If you don't think you'll use it, would you consider transferring ownership of the http-core
crate?
Some amount of no_std support could be incrementally added using this reserved crate. See #551.
Proposal
I noticed you've reserved the
http-core
crate. Would there be interest in moving some of the primitives fromhttp
down to it?I'm thinking:
Method
Version
StatusCode
Uri
HeaderName
HeaderValue
Motivation
These are the types we use and re-export from
http
in Actix Web.