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 _______________________________________________ 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
