[Web-SIG] WSGI adoption
ianb at colorstudy.com
Fri Nov 26 02:09:49 CET 2004
Alan Kennedy wrote:
> [Peter Hunt]
> > It's going slowly but surely, as I can tell from my Googling.
> Agreed: the google results for "download WSGI server" are disappointing,
> with one notable jythonic exception ;-)
For now the easiest thing would be for us to all put links in the Python
And maybe the WSGI PEP should link to that (since it's top result and
primary reference for "WSGI").
> > I think
> > we could speed adoption very quickly if we all got together and
> > created stable, tested, proven, and officialy WSGI gateways.
> I think we have a small perception problem, in that the existing WSGI
> servers and utilities are low visibility. They are all a part of another
> download, or reside in people's svn repositories, or are small utilities
> that don't have documentation, or even readily identifiable names .....
For the most part they are all in an alpha state. Well, at least mine
are; moreso, some pieces of WSGIKit are merely placeholders.
> I think there are currently three pure python WSGI servers derived from
> SimpleHTTPServer. Perhaps someone could take it on themselves to go the
> last few steps and give one of them a name, write some simple
> WSGI-focussed docs, a setup.py and prepare a download package?
> > 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
> Definitely the most important. And at least one already exists. All it
> requires is a little packaging.
> > - FastCGI
> I think this is more of minority architecture myself.
FastCGI is a pain in the butt. But there should be a couple servers
along these lines; a multiprocess server and a threaded server. Maybe
it can be part of an HTTPServer implementation; perhaps pluggable so
that the server could serve HTTP, FastCGI, and some of the FastCGI
knockoffs (PCGI, SCGI, mod_webkit, mod_skunk, etc).
> > - mod_python
> This is the mainstream. Until WSGI has clear mod_python support, it
> won't "have arrived", IMHO.
While it should certainly be in there (and shouldn't be too hard),
mod_python isn't particularly mainstream IMHO.
> > - Microsoft ASP+Python
> That is an interesting one. I had originally thought this wouldn't be
> possible, since ASP is by definition a templating language, meaning that
> the user's python code is executed at the leaves of an HTML object
> structure inside the server, and that it wouldn't be possible to
> circumvent that to provide the flow control that WSGI requires.
> But there's no reason why a python.asp page could not just consist of a
> simple document containing nothing but a WSGI invoker. Although it might
> be difficult to separate out the URL resolution: IIS might insist on
> resolving URLs to ASP pages itself, meaning that quixote-style
> step-by-step url resolution might not be possible, for example. I don't
> use IIS for anything but web-services, so I don't know this detail.
I would guess that http://server/page.asp/path/to/component would be
easy enough to do.
> > - Twisted
> > - Zope (2 or 3)
> I think at least part of the reason why we have so many python web
> frameworks, and indeed WSGI, is because people want/need something
> simpler and lighter than these heavyweights.
Twisted is a big install, but it's not actually very heavy. I think
it's quite reasonable that we'd use Twisted as a base instead of
SimpleHTTPServer, at least in the long run. I'd like to see other
access methods so it doesn't require a ProxyPass setup to work with
Apache (somehow ProxyPass makes me uncomfortable). And a multi-process
option, which could run underneath. The installation size is also a
problem, but the Twisted people have been talking about breaking the
package up into smaller bits.
I feel more comfortable using Twisted for handling sockets and
connections than anything we code up on our own; I've never trusted
Webware's multi-threaded socket handling. If not Twisted, then Medusa.
Zope 3 could be a WSGI application; I don't think the server bits are
very interesting. It's still just a Medusa server, right? It would be
interesting as a server if you had a WSGI product, so you could attach a
WSGI application underneath a Zope 3 server
Most of that applies to Zope 2, but Zope 2 has a larger install base and
a more opaque installation, so I think it might be more advantageous.
Part of WSGI (to me) isn't just to create new lighter frameworks, but to
allow for more heterogeneous Python web systems, and to make WSGI-based
applications easier to install, maintain, and integrate. If someone
makes a really good WSGI webmail app, it would be nice to be able to
integrate that inside any system, including Zope. OTOH, Zope isn't a
prerequesite for anything, it'd just be nice to see sometime in the
future. It's entirely possible I'll do it myself sometime if I want to
run a Webware application into Zope; it hasn't happened yet, but most of
the pieces are in place.
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG