[Web-SIG] ngx.poll extension (was Re: Are you going to convert Pylons code into Python 3000?)

[Phillip J. Eby]

At 09:37 AM 3/6/2008 +1100, Graham Dumpleton wrote:
>You probably need to explain the second half of that sentence a bit
>better. From memory the WSGI 1.0 specification says that for an
>iterable, the headers should be sent upon the generation of the first
>non empty string being yielded. How does what you are doing relate to
>that, are you not doing that? Why would WSGI 2.0 necessarily be any
>different and cause a problem?

Because (in concept anyway) WSGI 2.0 is synchronous with respect to 
headers -- you don't get to yield empty strings and *then* return the headers.

Personally, I see truly-async web apps as a niche, because in order 
to write a useful async app, you need *other* async APIs besides your 
incoming HTTP one.  Which means you're going to have to write to 
Twisted or some other library's API, or else roll your own.  At which 
point, connecting your app to a web server is the least of your 
concerns.  (Since it has to be a web server that's compatible with 
the API you're using, which means you might as well use its native API.)

That having been said, I don't see a problem with having a Web Server 
Asynchronous Interface (WSAI?) for folks who want that sort of 
thing.  Ideally, such a thing would be the CPS (continuation-passing 
style) mirror of WSGI 2.0.  Where in WSGI 2.0 you return a 3-tuple, 
in WSAI you'd essentially use start_response() and write().

In essence, you might say that WSGI 1.0 is a broken-down version of a 
hideous crossbreeding of pure WSGI and pure WSAI.  It would probably 
be better to split them and have bridges.  A truly-async system like 
Twisted has to (effectively) do WSAI-WSGI bridging right now, but if 
we had a WSAI standard, then there could perhaps be third-party bridges.

Even so, it's quite a niche: Twisted, nginx, and...?  I know there 
are a handful of async frameworks, and how many of those have web 
servers included?