[Web-SIG] WSGI adoption

Phillip J. Eby pje at telecommunity.com
Thu Nov 25 19:05:23 CET 2004


At 12:38 PM 11/25/04 -0500, Peter Hunt wrote:
>It's going slowly but surely, as I can tell from my Googling. I think
>we could speed adoption very quickly if we all got together and
>created stable, tested, proven, and officialy WSGI gateways.
>
>I think the following list would be a good place to start, with the
>important ones first and the less-important ones near the bottom:
>
>- CGI
>- FastCGI
>- mod_python
>- Microsoft ASP+Python
>- Twisted
>- Zope (2 or 3)
>
>What do you guys think?

I do intend to add mod_python and Twisted gateways to 'wsgiref', in 
addition to the CGI gateway that's already in it.  For FastCGI, the PEAK 
runners have been stable for some time, since I originally built them with 
an older, more CGI-like WSGI, over a year ago.

That leaves ASP+Python and Zope.  I don't have any experience with (or 
access to) the former, but I gather that the Zope Corp. folks are more 
interested in getting Zope to run under other servers (especially Twisted 
and Apache) than they are in getting other WSGI stuff to run under the Zope 
servers.  I agree, at least from the perspective that until WSGI has enough 
application and framework support, there isn't going to be as much demand 
for running WSGI apps under Zope servers.


>If we go to all the framework writers and say
>"if you adopt WSGI your framework will automatically run on all of
>these platforms", don't you think it's a no-brainer to support it?

What I'd really like to do next is standardize on a deployment 
configuration format (preferably ConfigParser-based, as the format is 
simple, and support is in the stdlib).

One big advantage of having such a format is that I could implement basic 
support for it in 'wsgiref', such that a given server just needs to call a 
function with a filename (or stream, perhaps) to load up a 
nicely-configured application object, all ready for use with the 
appropriate WSGI handler class.  Thus, all the wsgiref-based servers would 
enjoy instant access to the deployment format.

At that point, the documentation needed for an end user to deploy something 
is just how to tell a given web server where the deployment file is, and 
what URL it should be made available under.  And, for the framework or 
application author, they just need to document what should go in the file.



More information about the Web-SIG mailing list