[Twisted-web] Twisted.web2

[James Y Knight]

On Sep 15, 2004, at 12:26 PM, William Dode wrote:
> James Y Knight <foom at fuhm.net> writes:
>> 3) For distribution: twisted.web2 depends on Nevow (for static
>> directory listings, and error pages), so will be distributed with
>> it. Nevow recommends Twisted but does not require it for simple cases
>> (e.g. flattening to a string from a CGI script), so there can also be
>> a limited-functionality distribution of standalone Nevow.
>
> What about the wsgi spec ?
> http://www.python.org/peps/pep-0333.html

The WSGI spec is near irrelevant for a twisted web application.

There are two components to look at here:
1) Can we support running WSGI applications?
WSGI specifies blocking behavior and thus cannot be used in twisted as 
the primary, or even a recommended, interface. It is possible to write 
a WSGI application runner for twistedweb, but it would have to either 
spawn a thread or process for each simultaneous WSGI request. Twisted's 
whole architecture is geared towards not having to do that, thus, an 
API that requires it is decidedly second-class and something that isn't 
very high on my list of things I care about.

2) Can we run *as* a WSGI application?
No, not really. WSGI has 4 different modes a client might be run in: 1) 
threads in the same process for each simultaneous request, 2) a process 
for each simultaneous request 3) multiple processes and a thread in one 
of those processes for each simultaneous request (kind of like 1&2 
combined). 4) Spawn a new process for each request and the process ends 
when the request is done.

Twisted web prefers to run all requests in a single thread. Therefore, 
none of the alternatives are very well matches. It could probably work 
in mode 2 and 4, although not ideally, but not in mode 1 and 3, because 
twisted is generally not threadsafe, so running essentially two copies 
of twisted in one process will not work.

I wrote preliminary support for running twisted as a CGI (essentially 
equivilent to wsgi mode 4) except more generally useful. Clearly this 
is not ideal but I think it's useful to have a simple way to integrate 
some twisted stuff into a hostile environment.

We could make a WSGI application that just send the requests over a 
socket to twisted web running in a separate process, but there's not 
really any reason to IMO. HTTP is already a good protocol for talking 
over sockets. Use apache mod_proxy to send requests to the twisted.web 
process. There's also the SCGI socket protocol which looks reasonable 
and we might want to support.

> It could be great if the server could not depend on any framework (i
> mean nevow).

It will use nevow to render the pages the webserver generates, such as 
errors and directory listings. This does not mean you need to use nevow 
for your own pages. You can use whatever templating language you want 
(or none at all) to render your pages, assuming you can hook it up to 
twisted web somehow.

If you want to make a custom hacked-up copy of twisted.web without 
Nevow included, it will work, other than default server-generated 
pages. However, I don't see any reason to not include it by default.

James