[Twisted-web] Re: [Web-SIG] A more Twisted approach to async apps in WSGI

[Phillip J. Eby]

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 
>twisted server.

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 
to fit.

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.