[Web-SIG] Re: Preferred set of WSGI servers

[Rene Dudfield]

On 4/30/05, Steve Holden <steve at holdenweb.com> wrote:
> Ian Bicking wrote:
> > Peter Hunt wrote:
> >
> >> Actually, I think a mod_wsgi for Apache and IIS would be one of _the_
> >> most important things for WSGI. I think that it would search for a
> >> __wsgi__.py file (or maybe something with a better name) which would
> >> expose a WSGI application named "application" that would handle
> >> requests for the directory in which it exists. This would allow a user
> >> to simply drop a file on the webserver and have it work. It would be
> >> excellent for shared hosting solutions.
> >
> >
> > Would it?  From what I can tell, mod_php is very popular in shared
> > hosts, but neither mod_python nor mod_perl are.  I don't think mod_*
> > makes it necessarily host-friendly.  But from what I can tell of
> > mod_python, it would be relatively easy to have something like .wsgi
> > files, and give them a handler that runs them as WSGI apps.
> >
> > I can imagine a good setup for hosts being one based on forking per-user
> > processes, which is adaptive primarily to scale down -- e.g., a largely
> > dorman app could have 1 or even 0 processes running (at 0 it becomes
> > similar to CGI, but presumably the process would stay around for some
> > time to respond to subsequent requests).  The "scaling down" scenario I
> > often think about would be a email contact form -- one of those things
> > that has to be an app, can be implemented and deployed separately from
> > other aspects of the site, and yet it's clear waste of resources to keep
> > a process always around to respond to such requests.  Though it's
> > actually someplace where CGI would work just fine; but lets say you
> > don't want to educate the developer about when they might want to use
> > other deployment strategies (which is a rather complex discussion
> > really, that would be better avoided by providing one really good
> > strategy and telling everyone to use it).
> >
> > Maybe mod_python is appropriate for that kind of situation, I'm not
> > sure.  It could also be implemented with a second, single process that
> > was developed and deployed separately from Apache.
> >
> > As for IIS and ISAPI, I can't say I really know what the archicture of
> > that system is, so I don't know.  Oh, but that does remind me of another
> > WSGI server: ASP.  Though I remember vaguely this came up before and it
> > seemed infeasible because ASP didn't support anything like PATH_INFO. Oh
> > well, I can't remember now.
> >
> Seems to me that mod_python isn't really suitable for a shared-hosting
> environment because of the need to restart the server when
> indirectly-imported modules are updated, a situation that I believe
> mod_python does not detect.
> 


I think this is changed since a recent python2.4?  Not sure if it also
affects mod_python...


from the release notes 'What's New in Python 2.4?':
http://www.python.org/2.4.1/NEWS.html

"""When importing a module M raises an exception, Python no longer
leaves M in sys.modules. Before 2.4a2 it did, and a subsequent import
of M would succeed, picking up a module object from sys.modules
reflecting as much of the initialization of M as completed before the
exception was raised. Subsequent imports got no indication that M was
in a partially- initialized state, and the importers could get into
arbitrarily bad trouble as a result (the M they got was in an
unintended state, arbitrarily far removed from M's author's intent).
Now subsequent imports of M will continue raising exceptions (but if,
for example, the source code for M is edited between import attempts,
then perhaps later attempts will succeed, or raise a different
exception).

This can break existing code, but in such cases the code was probably
working before by accident. In the Python source, the only case of
breakage discovered was in a test accidentally relying on a damaged
module remaining in sys.modules. Cases are also known where tests
deliberately provoking import errors remove damaged modules from
sys.modules themselves, and such tests will break now if they do an
unconditional del sys.modules[M]."""



Cheers,

Rene Dudfield

e: "@".join( reversed(['madecollective.com', 'rene']) )
w: http://www.madecollective.com/
w: http://www.pretendpaper.com/
For creative, and technical services contact us @ made.