[Twisted-web] Re: [Web-SIG] A more Twisted approach to
async apps in WSGI
Phillip J. Eby
pje at telecommunity.com
Fri Oct 15 17:52:58 CEST 2004
At 11:20 AM 10/15/04 -0400, James Y Knight wrote:
>On Oct 7, 2004, at 1:28 AM, Phillip J. Eby wrote:
>>By the way, after all this discussion... do you think it would be better to:
>>1) Push towards a full async API, nailing down all these loose ends
>>2) Use the simple-but-klugdy "pause iteration" API idea
>>3) Don't make an "official" async API, and just leave it open to server
>>authors to create their own extensions, and maybe cherry pick the best
>>ideas for WSGI 2.0, or
>>4) Do something else altogether?
>I think the API you've outlined sounds good. I can imagine ways to
>implement it both for an async server like twisted, and as a compatibility
>layer for an async-requiring application on a sync server. I think it's
>easier to make the compatibility layer with this API than with the
>pause/resume API. However, I would be quite wary of including it in the
>final spec without it being implemented first.
Right, this is one reason I'm thinking that #3 might be a good idea,
although it'd probably be more like 1.1 than 2.0. Or really, it would just
be an optional extension available under 1.0. Even if we finalize the 1.0
spec, nothing stops us from adding optional extensions that don't alter the
existing required semantics.
>Another question is: what is the current use for it? Does anyone want to
>write untwisted async web applications?
Right. That's the really big issue, and another reason why saying, "let's
wait for implementations" might be a good idea. That is, if people
implement something, there's clearly a market for it. If they don't, maybe
we don't need it.
>My current interest in WSGI is basically on the "plug twisted web into
>another webserver as an application" side of things. I wouldn't want to
>write an application to WSGI (without a framework on top)... If everyone
>else feels that way, an async API may not be actually useful until there
>is some other Async-WSGI web server that you could plug twisted framework
>stuff on top of, or some other async framework you can plug on top of the
Yep, that's the issue alright. It seems that the common usecase for an
async web app is going to boil down to: "do you want to proxy your Twisted
app from some other web server?" Because let's face it, Twisted's process
model isn't really a match for say, the Apache prefork model, or CGI.
ISTM, then, that the useful thing to write would be a synchronous
WSGI->HTTP "application" object. That would allow Twisted or any other
async server (or really any HTTP server at all) to be treated as a WSGI
application, thus letting async apps join the WSGI party without forcing
them to give up any asyncness or to have to do other really horrid things
With a little more sophistication, such an application component could
perhaps actually spawn the async server if it's not running, by checking a
pid file or some such. Or that could be middleware; you have a "server
starter" middleware that just ensures the server is running before it
passes the request down to the proxy middleware.
>As for postponing until WSGI 2.0, I would hope there doesn't need to be a
>WSGI 2.0, though, since the interface is so darn simple. ;) But it could
>be in a separate WSGI async addons.
Technically, I don't think finalizing the base specification would prevent
us from amending the PEP to add optional features even to 1.0.
More information about the Web-SIG