[Web-SIG] Re: Regarding the WSGI draft

[Phillip J. Eby]

At 04:15 PM 8/27/04 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>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.
>
>I happened to be playing with just such a thing:
>
>http://colorstudy.com/cgi-bin/viewcvs.cgi/trunk/WSGI/pycgiwrapper.py?rev=206&view=log

Wow; you certainly thought this through more than I did.  E.g. your model 
for dealing with threads.  The part for dealing with missing 
threads/threading though should probably use dummy_threading, though.

Also, I notice that you're using multiple 'environ' replacements for some 
reason, even though any use of it is going to be wrapped in a global thread 
lock.  So, the '_environs' dictionary seems superfluous.  A minimal 
approach to adjusting the FieldStorage class could be:

    cgi.FieldStorage.__init__.im_func.func_defaults=(None,None,"",environ,0,0)

which will make the default environ be the one you want.  Doing that, and 
replacing 'os.environ' for the request's duration (and putting them back 
when done) seem to be required.  (Note that code that doesn't use the 'cgi' 
module but directly checks os.environ won't work with the current state of 
things.)

Hm.  Actually, I just looked and it looks like you're not wrapping the 
execution in the global mutex, but you really need to because not only are 
sys.std* global, CGI apps aren't generally written to be multithreaded.

Nice design otherwise, though.  I particularly like that if you don't want 
to run a script file, you can just override 'run_script' to do whatever the 
request body is.


>There's a few parts I kind of punted on, though now that I think about it 
>I know what I did wrong, so I'll fix it a bit this evening.  Anyway, it's 
>intended to work both for multiprocess (e.g., mod_python) and threaded 
>servers, with decreasing likelihood that any particular script will 
>actually work.
>
>But I haven't yet tested it under anything but CGI, so it really *should* 
>work ;)  I'll try running it with your WSGIServer and see how it goes.

Don't forget: WSGIServer has *not* been updated to PEP 333 yet; it's still 
based on the old streaming approach!  I've been too busy updating the spec 
(and replying to every thread) to update the code.  :)