At 04:25 AM 1/9/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-08 13:16:52 -0800, P.J. Eby said:
In the limit case, it appears that any WSGI 1 server could provide
an (emulated) async WSGI2 implementation, simply by wrapping WSGI2
apps with a finished version of the decorator in my sketch.
Or, since users could do it themselves, this would mean that WSGI2
deployment wouldn't be dependent on all server implementers
immediately turning out their own WSGI2 implementations.
This, if you'll pardon my language, is bloody awesome. :D That
would strongly drive adoption of WSGI2. Note that adapting a WSGI1
application to WSGI2 server would likewise be very handy, and I
suspect, even easier to implement.
I very much doubt that. You'd need greenlets or a thread with a
communication channel in order to support WSGI 1 apps that use write() calls.
By the way, I don't really see the point of the new sketches you're
doing, as they aren't nearly as general as the one I've already done,
but still have the same fundamental limitation: wsgi.input.
If wsgi.input offers any synchronous methods, then they must be used
from a future and must somehow raise an error when called from within
the application -- otherwise it would block, nullifying the point of
having a generator-based API.
If it offers only asynchronous methods, OTOH, then you can't pass
wsgi.input to any existing libraries (e.g. the cgi module).
The latter problem is the worse one, because it means that the
translation of an app between my original WSGI2 API and the current
sketch is no longer just "replace 'return' with 'yield'".
The only way this would work is if WSGI applications are still
allowed to be written in a blocking style. Greenlet-based frameworks
would have no problem with this, of course, but servers like Twisted
would still have to run WSGI apps in a worker thread pool, just
because they *might* block.
If we're okay with this as a limitation, then adding _async method
variants that return futures might work, and we can proceed from there.
Mostly, though, it seems to me that the need to be able to write
blocking code does away with most of the benefit of trying to have a
single API in the first place. Either everyone ends up putting their
whole app into a future, or else the server has to accept that the
app could block... and put it into a future for them. ;-)
So, the former case will be unacceptable to app developers who don't
feel a need for async code, and the latter doesn't seem to offer
anything to the developers of non-blocking servers.
(The exception to these conditions, of course, are greenlet-based
servers, but they can run WSGI *1* apps in a non-blocking way, and so
have no need for a new protocol.)
_______________________________________________
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
