Hi Mat,

On 01/12/2016 04:23 PM, Mat Clayton wrote:
> +1 as well, this is really great work, on both patches!
> 
> Modifying the middleware stack mid request would be very useful for us.
> 
> We currently run 3 copies of the same code, with essentially different
> urls.py and middlewares loaded, each one is used to run a variation of
> the site, for example www/mobile web and api, and have slightly
> different requirements, which are handled in middlewares, for example
> api calls are authenticated by access tokens and www/mobile use cookies.
> 
> Ideally we'd love to consolidate our deployment into a single set of
> python web workers, but to date its been a little too complex to be
> worth it. We could however use the url dispatching patch and PR1 to
> write a middleware which could load in the necessary middleware stack
> based on the requirements of each request.
> 
> So my preference therefore would be for PR1 as I can see a few edge
> cases it would enable solutions for.

I don't think it's worth penalizing the performance of the common case
in order to enable these edge cases. I think it should be possible to
add a "per-request middleware" feature atop PR #2 in a fully
backwards-compatible way without compromising performance in the common
case (essentially by compiling multiple alternative request-paths in the
handler instead of just one), but this should be handled as a separate
feature, built in a separate pull request; it's out of scope for DEP 5.
It solves a completely different problem from the one DEP 5 is aiming to
solve.

I also think there are fairly easy ways to solve your problem in the
meantime without the per-request middleware feature, for instance with
hybrid middleware that conditionally does something-vs-nothing (or
one-thing-vs-another) depending on some attribute attached to the request.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/569D79B2.60601%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to