ServiceFn takes a closure and impls Service.

[carllerche]

ServiceFn services are always ready. It is expected that a middleware
implements a rate limiting strategy.

[carllerche]

I'm wondering if this is not a great API.... or at least there needs to be another one that takes Fn and wraps in an Arc.

[seanmonstar]

What's the proposed Arc for? You mean for making a NewService of this?

[carllerche]

I'm wondering if ServiceFn should always take T: Fn (instead of FnMut) and stash it in an Arc. Then ServiceFn can impl NewService as well.

Basically, ServiceFn is for convenience.

[seanmonstar]

I thought a lot about this for hyper's local service_fn helpers. I think it probably does make sense to just take Fn, since otherwise, it would be easy for a user to think that mutating captured environment in the closure is noticeable globally, but it'd only be per-service (connection).

In the upcoming Rust release, closures will derive Copy/Clone automatically, which could mean an Arc isn't needed... though, if the captured environment includes big values, copies might be more expensive than an Arc.

[carllerche]

@seanmonstar it also might not be obvious why an fn isn't clone, which might lead to confusing errors.

[carllerche]

I don't remember the conclusion of this :'(

[carllerche]

I think there should be a type that takes Fn(...) + Sync, wrap it in an Arc and impl NewService + Service.

Any thoughts re: what that type should be?

[carllerche]

Gone stale.