Closed davidpeden3 closed 7 years ago
@davidfowl let's not, this is going to make the perf even worse.
Let's see some measurements before making those claims. Caching non generic tasks are super easy. As soon as we get rules that read the request body or write to the response body then we need an async option.
Also, it's a pretty big breaking change for anyone that's already implemented rules.
We can make breaking changes in 2.0 and my guess is that we wrote most of the rules since this middleware hasn't been around that wrong.
@Tratcher is this what you were suggesting?
https://gist.github.com/davidpeden3/1ef73ea305fe262da5aab60150219131
@muratg I thought this one was done. But it was unclear if you guys wanted to merge it in. Can you clarify the status? Thanks.
The question of usefulness vs perf impact was never resolved. That's on us to resolve. @davidfowl
Super easy to write a micro benchmark for this so lets do that.
/cc @muratg can you assign somebody to do this?
@mikaelm12 could you write a couple micro-benchmarks testing this?
@mikaelm12 can you post your results? thanks
@davidpeden3 I should have commented when I closed this, sorry.
Unfortunately with all the work we've been doing for 2.0. This didn't make it in 🙁
We still very much appreciate your contributions though!
@muratg Could we consider this for 2.1? I can try to get this in based on performance results.
Changing the IRule
interface, wouldn't that constitute a breaking change?
@JunTaoLuo is right. We would either need to add a second interface (IAsyncRule) or something else that is hacky.
Hi @davidpeden3, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution! You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;