[Web-SIG] PEP 444 feature request - Futures executor

[P.J. Eby]

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.