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
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
