Warp: Why are all extensible structs, types, and traits hidden?

[kitsuneninetails]

I, for the life of me, cannot understand why all of the extensibility of warp is thrown behind artificial privacy mechanisms, such as pub(crate), private mods, and mod sealed.

There are so many cool things we, as users, could do with warp to make it more extensible, make libraries, standard filter-sets, etc., but we cannot, because all of the traits and structs we need (Filter, One, and Tuple, for starters) are hidden. Why? It makes no sense to me. These aren't hidden implementation details. These are the life blood of what makes warp tick, and what would provide us a way to make it tick even better in our use cases. Those aren't supposed to go behind privacy mechanisms. What goes into private crates are low-level implementations, backside details that can't be extended and aren't a major part of your API, and no one in any use case would need.

Filter IS the warp API (or at least a pretty big chunk), yet it is hidden away and not extendable, so we can't make our own filters to make a nice, awesome filter library; instead we MUST rely on what the developer has decreed is useful for a web server? That doesn't seem like an open, modular strategy. Furthermore, One/Tuple, etc. are all types and traits we would need to make library functions that can handle replies, etc. but we can't, because they are also hidden away.

It is extremely frustrating to see the tools I need locked behind the glass display case for no discernible reason.

Is there any reason you can't change all of these mechanisms to make important traits (the ones I listed, for a start) public, and then trust us to know how to program well-enough to use them?

[mikeplus64]

It is also a bit annoying sometimes trying to follow what some things actually are -- like allow_origin and allow_origins accept an IntoOrigin as a parameter. But what is an IntoOrigin? If we dive into the source it turns out to be a trait only implemented for &str (n.b. which is a bit suspect, it'd be nice to have a impl IntoOrigin<Origin> for Origin as the default parsing does not support ports whereas plain-old Origin does)

I suggest exporting internal modules explicitly as internal as an easy-ish first step.

(Otherwise I've really enjoyed using warp :))

[carllerche]

As a general point of feedback, the tone of the issue comes off as aggressive and will most likely put the maintainers on the defensive.

I would suggest revisiting the issue to try for a more constructive tone.

[davidpdrsn]

While I do agree the tone of voice is not constructive I do agree with the general sentiment. I also think it would be cool if more of the underlaying API was exposed so users could build things on top of it.

For example I would really like to build custom "middlewares" that are added using the .with combinator on Filter but that currently isn't possible because Wrap is private.

Is opening up some of the currently private APIs something you would be willing to consider?

[seanmonstar]

I recognize some things may seem arbitrarily hidden, but I assure you, a lot of thought was put into exactly how to expose things. It can certainly be frustrating, especially when you're excited to build something and it seems stuff is just out of reach. That said, I'm going to close this issue due to the tone. We all do open source work because we enjoy sharing cool things with others, so I'd rather figure out how to address issues in a less aggressive issue.

For any specific thing that is currently "private", we can open a specific issue for it, and discuss why it was private, whether that is still necessary, and if we could make it public (I think the answer to Wrap is basically "let's just unseal it already").