[Web-SIG] Server-side async API implementation sketches

[P.J. Eby]

At 04:25 AM 1/9/2011 -0800, Alice Bevan­McGregor 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.)