[Web-SIG] Proposal for asynchronous WSGI variant

[Christopher Stawarz]

On May 7, 2008, at 5:36 PM, Ionel Maries Cristian wrote:

> The way I see it asynchronous wsgi is just a matter of deciding how  
> to handle the input asynchronously - a asynchronous input wsgi  
> extension specification.

Another crucial element is the ability to perform non-blocking I/O on  
other file descriptors (TCP connections to other servers, pipes to  
other OS processes).  This is why the readable/writable functions (or  
something like them) are necessary.

> So I suggest completely dropping the idea of a incompatibility  
> between async_wsgi and wsgi (since it doesn't help anyone in the  
> long run really - it just fragments the gateway providers and  
> overcomplicate things) and concentrate more on the async input  
> extension.

This is a compelling argument.  As long as the application iterable  
yields only strings (which, the more I think about it, seems like the  
right thing to do), then the remaining functionality I propose can be  
implemented as extensions to WSGI, perhaps in a "x-wsgiorg.async"  
namespace.

However, the problem remains that, even though an asynchronous server  
can implement the write() callable and wsgi.input as required by the  
WSGI spec, they effectively can't be used by applications, since they  
involve potentially blocking I/O operations.  So either WSGI has to be  
revised to take the needs of asynchronous servers into account, or we  
have to accept that async servers can never be fully WSGI compliant.

> So the idea is that the gateways would provide async input by  
> default and a piece of middleware or config option to make it  
> synchronous (well, actually, buffer it).

You mean the middleware would be used to make the input synchronous so  
that an app that uses wsgi.input would function normally (reading from  
the buffer)?  That would fix the problem for wsgi.input, but the issue  
with write() remains.

Another point to keep in mind is that in order to function correctly  
on an async server, an application really has to be written with that  
execution environment in mind.  For example, an app couldn't use  
httplib, since it does blocking I/O (which, again, would freeze up the  
entire server).

> Also, since there already are a bunch of async gateways out there I  
> would like to hear if the other providers would/could implement the  
> proposed form of common async input - that would ultimately decide  
> the success of this proposed spec.

I would like to hear their opinions as well.  In particular, do any  
Twisted folks have comments on what we've discussed?


Chris