[Web-SIG] WSGI adoption

Peter Hunt floydophone at gmail.com
Thu Nov 25 22:57:30 CET 2004


Fair enough; we can drop Zope from the priority list.

I'd suggest simply using plain Python as a configuration file format.
It's just as easy to understand and far more flexible than
ConfigParser.

Also, in terms of configuration files, I think an instance of each
middleware/application/gateway should get its own configuration file.
While designing this configuration system, we should keep the idea of
shared hosting in mind, and that the host may want to run certain
pieces of middleware for everyone.

On Thu, 25 Nov 2004 13:05:23 -0500, Phillip J. Eby
<pje at telecommunity.com> wrote:
> 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