[Web-SIG] [extension] x-wsgiorg.flush

[Phillip J. Eby]

At 05:00 PM 10/4/2007 +0200, Manlio Perillo wrote:
>Your are making a critical decision here.
>You are lowering the level of WSGI to match the level of average WSGI
>middlewares programmers.

No, we're just getting rid of legacy cruft that's hard to support 
correctly.  There's a big difference.


>This can have disastrous conseguences if Python will gain a large user
>base in the future (and, of course, with a large user base, the majority
>of the users will have a low profile).

This seems to be arguing the opposite: making WSGI simpler is a 
*good* thing if there will be a larger user base.


> >> It's very unfortunate that the WSGI implementation in Twisted just uses
> >> threads instead of doing some experimentation.
> >
> > You're making the assumption that no experimentation was done.  Check
> > the Web-SIG archives from three years ago and see the discussions about
> > async APIs.
>
>No.
>I have read a lot of archived messages, and all I have seen are
>*discussions* about asynchronous extensions, but no working implementations.

Because nobody came up with anything particularly useful.  While it's 
possible to have generic extensions for pausing and resuming 
iteration, those aren't useful enough to write a fully asynchronous 
application.  You still have to block and/or poll in order to do 
anything else.  Meanwhile, since applications *can* block, they have 
to be in a separate thread or process from an async server 
anyway.  So all that asynchrony does is free up the thread or process 
to handle something else...  which is wasted if the app is not in an 
async server.

So, barring a radical alteration to the WSGI programming model, 
asynchronous programming is a bit of a dead-end.  To do async right, 
you really need a CPS (continuation-passing style) API, *and* you 
also need async APIs for whatever the app is going to *do*.

In other words, the absence of standard Python APIs for asynchronous 
I/O (be it socket, database, or otherwise) make it moot to add an 
async API to WSGI, since in practice the application will be 
locked-in to whatever async I/O API it uses.