Expose HeaderMap in addition to HeaderIter for twilight-http responses about twilight HOT 9 CLOSED

There's generally two reasons for us not wishing to expose dependencies publically:

1. Makes certain refactors, such as switching dependencies, impossible
2. Ties us to the semver compatible version until we issue a breaking release ourselves.

http 0.2 was released in december 2019, and 0.1 was released in september 2017, compared to Twilight 0.15, which was released just this february. Looking at the version history it's clear that Twilight will not suffer from exposing http 0.2 publically; the next semver breaking version is never too far away. Additionally, http is the definitive HTTP crate for Rust and I don't see a future where Twilight doesn't use it.

On the flip side, we shouldn't eagerly expose dependencies just because. Every API addition further ties down our ability to refactor.

It's not unheard of to expose features tied to public versions, for example, a http-02 feature. That way an additional feature http-03 could be added, without breaking Twilight, when http 0.3 releases. However, this feature request is about adding an O(1) method for some header values (instead of linearely searching an iterator of every header), so I think it's just about adding one new method. Our current headers method on Response returns an iterator directly. Changing this to return a map that exposes a get and iter (and/or IntoIterator) method adds the least amount of friction whilst keeping the door open to future methods on the map. Could we receive further feature requests on this header map leading us to eventually re-implement the dependency? I don't think so, we're just worried about Discord responses and only need to provide immutable access to the headers.

Edit: After further discussion, it was brought up that http does not offer O(1) access to headers via HeaderMap. Thus, the current behaviour of just exposing a header iterator should be fine---the HeaderMap interface can be simulated with methods on Iterator.

from twilight.

Exposing HeaderMap would expose a dependency and that's something we don't do.
If you have an alternative idea for a solution let us know.

from twilight.

Add a get<'a>(&self, key: &'a str) -> Option<&[u8]> method on the HeaderIter?

from twilight.

Actually, should be get<'a>(&self, key: &'a str) -> Vec<&[u8]>, as headers are a multi-map.

from twilight.

I would also fancy an opt-in to get the inner type. This would mean exposing the dependency though. I would opt into seeing raw dependencies as well though - would that be an option? As in, exposing dependencies but only when the users explicitly opt-in.

from twilight.

Even if it is opt-in, exposing a dependency is something we want to avoid.

from twilight.

I'm on board with not exposing the dependencies as long as it doesn't cost me at runtime, otherwise, it seems like a wrong trade-off to me. Not saying this is a way to go for you or this project though.

Another option for me is to use an iterator to copy over all the headers and reconstruct the HeaderMap, but I don't like it for obvious reasons.

So, the best way, I'd say, is to add a get fn. That said, redoing the dependency is arguably worse than exposing it...

Here, for instance, the HeaderMap is used under the hood, it can be used outside, but there's no way to actually get the data without the overhead. The very thing that's being used is headers. I mean, I understand the idea behind your decision, but oh boy it's inconvenient... Doesn't worth the benefits it brings in my opinion.

from twilight.

It'd also be wise to note there's a certain development resource overhead associated with the not-exposing the dependencies rule in edge cases like this one. Meaning, responding to a feature request takes time, and if you weigh the time it would cost to deal with http 0.3 switch if it were to ever happen vs this - it'd probably win by a long shot. I mean, it also took time for me to go forth and submit the issue, for you to read and respond... But then, I understand the complexity of having a rule with exceptions - like, when and how to decide whether something should have a special treatment, how to maintain and communicate such a rule, who and how to make the decision - you know, complications all over. A trade-off as always.
Sorry to keep bothering you with this btw :D Again, you're doing a great job here! Hope my few cents help.

from twilight.

Doesn't FromIterator implementation on HeaderMap make this pretty convenient? Obviously there's the overhead of cloning it but for this we could have a map method that returns &HashMap for which HeaderMap implements TryFrom

from twilight.