Re: PEP 444 / WSGI 2 Async
Alice Bevan–McGregor <alice-h+KYGxXtFYrqlBn2x/[email protected]>
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <[email protected]> |
On 2011-01-07 22:13:17 -0800, Alex Grönholm said: > 08.01.2011 07:09, P.J. Eby wrote: >> On the plus side, the "run this in a future after the request" concept >> has some legs... [snip] > > What exactly does "run this in a future after the request" mean? There > seems to be some terminology confusion here. I suspect he's referring to some of the notes on the "PEP 444 feature request - Futures executor" thread and several of my illustrated use cases, notably: :: Image scaling (e.g. to multiple sizes) after uploading of an image to be scaled where the response (Congratulations, image uploded!) does not require the result of the scaling. :: Content indexing which can also be performed after returning the success page. The former would executor.submit() a number of scaling jobs, attach completion callbacks to perform some cleanup / database updating / etc., and return a response immediately. The latter is a single executor submission that is entirely non-time-critical. And likely other use cases as well. This (inclusion of an executor tuned to the underlying server in the environment) is one thing I think we can (almost) all agree is a good idea. :D Discussion on that particular idea should be relegated to the feature request thread, though. - Alice. _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org