Jake Goulding

> passing in a type that conditionally enables or disables the middleware Actually, why do you think this is the best path? Doesn't doing this *force* the decision to be...

> What would the compile time switch look like? I guess I was thinking something like ```rust #[cfg(feature = "cors")] fn enable_cors() -> impl Middleware { ... } // cors...

See also #10

Or even a set of metrics, which would lead to being able to decide what backend is useful 😇 Note that there is [a log middleware](https://github.com/carllerche/tower-web/tree/master/src/middleware/log) which has some amount...

If I understand, something like this would replicate today's behavior: ```rust #[accept("application/json")] fn compile(/* ... */) { /* ... */} ``` Would we allow multiple attributes? ```rust #[accept("application/json")] #[accept("text/json")] fn...

My opinion is that at *some* point, this needs to break down into a struct: ```rust struct Foo { accept: Option, connection: Option, cookie: Option, host: Option, } #[post("/test")] fn...

> There isn't a reason Ah, I assumed this was ultimately a limitation of the lack of generic constants / variadic types / etc.

Is there the possibility of an API like ```rust ServiceBuilder::new() .resource(MountBuilder.new().mount("/foo", resource)) ``` That is, Using `Resource` as the primary abstraction and having mounting reside atop that?

> it is much more verbose though For builder-heavy APIs, there are two primary tricks I use to reduce verbosity: 1. Add aliases for constructors — `mount()` instead of `MountBuilder.new()`,...

One thing that makes me lean towards the higher-order service is that it's similar to warp, similar to middleware, just regular Rust code, and *probably* more capable. For example, I...