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

[Manlio Perillo]

Phillip J. Eby ha scritto:
> 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.  


Yes, this is true.
But I have to say that:

1) the asynchronous model is the "right" model to use to develope
    robust and scalable applications (expecially in Python).

    The fact that it is a niche does not means that it should not be
    supported and promoted.

> Which means you're going to have to write to Twisted 
> or some other library's API, or else roll your own.  

This is true, but there are already some working(?) asynchronous clients:
pycurl and psycopg2.

You don't need to use the web server "private" API.

An HTTP client and an a database client is usually all you need in a web 
application (well, you usually need also an SMTP client, but since a 
server probably has a local SMTP daemon running, this should not be a 
problem)


> At which point, 
> connecting your app to a web server is the least of your concerns.  

This is not always true.

> (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.)
> 

No, this is not correct.
The ngx.poll extension should be easy to implement in a "standard" 
server (I would like to write a reference implementation for wsgiref).

Moreover it is not impossible to write a pure async WSGI implementation 
in Twisted Web, and then having it support the poll extension.

Then, a portable application can just use pycurl or psycopg2 + the poll 
extension and should be portable.

Of course many WSGI implementations will not implements an "optimized" 
version of the poll extension, but isn't the same true for 
wsgi.file_wrapper?

> 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().
> 

Why write?
It's only a problem.

An asynchronous application should just use a generator.
This solves some problems, like the consumer producer problem.

Moreover it is also more convienent to use (IMHO).

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

Yes, this is a problem
But what makes WSGI 1.0 great, is that it is able to support this niche.




Thanks   Manlio Perillo