[Web-SIG] WSGI adoption

[Ian Bicking]

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 
Wiki:

   http://python.org/moin/WSGIImplementations

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.
> 
> Definitely.
> 
> 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