[Web-SIG] [extension] x-wsgiorg.flush
Phillip J. Eby
pje at telecommunity.com
Thu Oct 4 17:55:08 CEST 2007
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.
More information about the Web-SIG
mailing list