At 11:47 AM 1/7/2011 -0600, Timothy Farrell wrote:
There has been much discussion about how to handle async in PEP 444
and that discussion centers around the use of futures. However, I'm
requesting that servers _optionally_ provide
environ['wsgi.executor'] as a futures executor that applications can
use for the purpose of doing something after the response is fully
sent to the client. This is feature request is designed to be
concurrency methodology agnostic.
Some example use cases are:
- send an email that might block on a slow email server (Alice, I
read what you said about Turbomail, but one product is not the
solution to all situations)
- initiate a database vacuum
- clean a cache
- build a cache
- compile statistics
When serving pages of an application, these are all things that
could be done after the response has been sent. Ideally these
things don't need to be done in a request thread and aren't
incredibly time-sensitive. It seems to me that futures would be an
ideal way of handling this.
Thoughts?
This seems like a potentially good way to do it; I suggest making it
a wsgi.org extension; see (and update)
http://www.wsgi.org/wsgi/Specifications with your proposal.
I would suggest including a simple sample executor wrapper that
servers could use to block all but the methods allowed by your
proposal. (i.e., presumably not shutdown(), for example.)
There are some other issues that might need to be addressed, like
maybe adding an attribute or two for the level of reliability
guaranteed by the executor, or allowing the app to request a given
reliability level. Specifically, it might be important to distinguish between:
* this will be run exactly once as long as the server doesn't crash
* this will eventually be run once, even if the server suffers a
fatal error between now and then
IOW, to indicate whether the thing being done is "transactional", so to speak.
I mean, I can imagine building a transactional service on top of the
basic service, by queuing task information externally, then just
using executor calls to pump the queue. But IMO it seems pretty
intrinsic to want that kind of persistence guarantee for at least the
email case, or, say, sending off a charge to a credit card or
something like that.
One other relevant use case: sometimes you want a long-running
process step that the user checks back in on periodically, so having
a way to get a "handle" for a future that can be kept in a session or
something might be important. Like, say, you're preparing a report
that will be viewed in the browser, and using meta-refresh or some
such to poll. The app needs to check on a previously queued future
and get its results.
I don't know how easy any of the above are to implement with the
futures API or your proposal, but they seem like worthwhile things to
have available, and actually would provide for some rich application
use cases. But if they're implementable over the futures API at all,
it should be possible to implement them as WSGI 1.x middleware or as
a server extension.
A spec like that definitely needs some thrashing out, but I don't
think it need derail any PEPs in progress: the API of such an
extension doesn't affect the basic WSGI protocol at all.
_______________________________________________
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
