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

[P.J. Eby]

As a semi-proof-of-concept, I whipped these up:

   http://peak.telecommunity.com/DevCenter/AsyncWSGISketch

It's an expanded version of my Coroutine concept, updated with sample 
server code for both a synchronous server and an asynchronous 
one.  The synchronous "server" is really just a decorator that wraps 
a WSGI2 async app with futures support, and handles pauses by simply 
waiting for the future to finish.

The asynchronous server is a bit more hand-wavy, in that there are 
some bits (clearly marked) that will be server/framework 
dependent.  However, they should be straightforward for a specialist 
in any given async framework to implement.

What is *most* handwavy at the moment, however, is in the details of 
precisely what one is allowed to "yield to".  I've written the 
sketches dealing only with PEP 3148 futures, but sockets were also 
proposed, and IMO there should be simple support for obtaining data 
from wsgi.input.

However, even this part is pretty easy to extrapolate: both server 
examples just add more type-testing branches in their 
"base_trampoline()" function, copying and modifying the existing 
branches that deal with futures.

The entire result is surprisingly compact -- each server weighed in 
at about 40 lines, and the common Coroutine class used by both adds 
another 60-something lines.

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.

True async API implementations would be more involved, of course -- 
using a WSGI2 decorator on say, Twisted's WSGI1 implementation, would 
give you no performance advantages vs. using Twisted's APIs 
directly.  But, as soon as someone wrote a Twisted-specific 
translation of my async-server sketch, such an app would be portable.

More discussion is still needed, but at this point I'm convinced the 
concept is *technically* feasible.  (Whether there's enough need in 
the "market" to make it worthwhile, is a separate question.)