[Twisted-web] Re: [Web-SIG] WSGI woes

[Phillip J. Eby]

At 08:37 PM 9/16/04 -0400, Peter Hunt wrote:
>Yes, but an async app running in an async server in a thread is
>overkill, don't you think? We don't need to spawn an extra thread to
>run it. I'm not talking about "possible", I'm talking about "optimal".

Nothing in the spec stops an async server from providing a configuration 
option to say, "this app+middleware combination is completely non-blocking, 
so don't bother running it in a separate thread".  I've just been speaking 
about the general case, and what the server is required to do to support 
the general case of "an arbitrary WSGI application", with no additional 
information.

In the same way, nothing in the spec stops servers from providing 
per-application configuration options for any number of extended behaviors; 
WSGI is a starting point for server capabilities, not an ending point.

Still, I will admit that I tend to speak of things almost as if WSGI were 
an ending point, because I just assume we're talking about what the spec 
should or should not *require* or *forbid*.  When a use case doesn't need 
any "musts" or "must nots" added (like your use case above), I tend not to 
focus on it directly, because it seems obvious to me that anybody can add 
it on if they like, as a server-specific extension.

So, this may lead sometimes to people getting the impression WSGI doesn't 
allow a use case that in fact it does; it's just that the use case should 
be implemented using an optional extension, rather than being considered a 
common case and made into a requirement.  If I tried to enumerate every 
possible optional extension to WSGI, I'd go mad sooner than you can say 
"Content-Transfer-Encoding".  :)