[Web-SIG] Re: Regarding the WSGI draft

[Phillip J. Eby]

At 09:40 PM 8/27/04 +0100, Paul Moore wrote:
>I have a server which
>runs MoinMoin and Roundup (among other web apps). MoinMoin runs under
>mod_python, whereas Roundup runs as its own server, accessed via
>Apache and mod_proxy. If I wanted to add PyBlosxom, I'd need to run
>it as CGI (which, given the server hardware, is horribly slow). The
>variety of servers and backends gets hard to manage (and that's just
>with 3 applications!)
>
>I'd much prefer to only use one underlying architecture (probably
>mod_python), but Roundup and PyBlosxom don't support it. Ben's idea
>of application writers being able to easily support multiple servers,
>much like the DB API supports multiple backends, would be a real
>bonus for me, as it would make it far more likely that I could do
>something like this. (Either because application writers would
>include additional support, or because it would be simple enough for
>me to add it myself).
>
>I get the impression that the WSGI idea of layering and middleware
>might make this more likely in the longer term, but I don't see how it
>might happen. It certainly doesn't make it seem like something I could
>do for myself with an existing application. Maybe I'm missing
>something crucial here, but I'd certainly like to see this clarified,
>if it's the case.

Well, if you can identify the top-level control point of PyBlosxom and 
Roundup, you can always try converting them to WSGI.  But, maybe if there's 
a stdlib module for WSGI utilities, a useful one would probably be 
something to run some code in such a way that it thinks it's running under 
CGI, even though it's really running under WSGI.  The degree to which this 
could be assured is of course dependent on precisely what the application 
*does*, but getting 80% of CGIs (that don't depend on some kind of global 
state that isn't reset after each execution) to be able to run in arbitrary 
WSGI servers would be a handy thing, and most appropriate for the stdlib.

Anybody want to volunteer to write it?  ;)  If it helps, WSGIServer has 
some code for parsing stdout headers; see:

http://cvs.eby-sarna.com/PEAK/src/peak/util/WSGIServer.py?rev=1.3&content-type=text/vnd.viewcvs-markup

in the WSGIRequestHandler class.  (Note: this is the code I mentioned 
that's based on the December WSGI draft, where the response status and 
headers were embedded in the output stream rather than being function 
arguments.  So don't use it as an example of a proper WSGI server at the 
moment!)

(Offtopic, I'd note that a major reason PyBlosxom is slow may have nothing 
to do with CGI: my offhand impression of its code is that it appears to 
scan through file directories for every page rendering, just to do things 
like find what "flavours" might be defined in some of your post 
directories.  But I could be wrong, and there may be some "caching" plugins 
that would help this.)