[Web-SIG] WSGI adoption

[Alan Kennedy]

[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 ;-)

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

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.

 > - mod_python

This is the mainstream. Until WSGI has clear mod_python support, it 
won't "have arrived", 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.

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

 > What do you guys think? 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?

A lot of framework authors are definitely working on WSGI: I've read 
about such work in relation to JonPy, CherryPy, SkunkWeb, WebWare, 
Snakelets, and Python.Web. I'm sure there are others.

But if we're going to address perceptions such as this

 >>>> [WSGI support] not my goal.  One of my goals is to have Quixote
 >>>> work with as many HTTP servers as possible and to make it easy to
 >>>> switch between them.
 >>
 >> Upon that response is probably more cryptic than necessary.  What I
 >> mean is that WSGI support itself means nothing to me.  If supporting
 >> WSGI allows me to achieve my real goal then it will be supported.

then we have to demonstrate at least diversity of support: not all 
framework authors have to time to read PEP-333 in detail. Once WSGI is 
well established, universality of support won't be far behind.

The Blue Sky World is coming: can't you see that patch of blue over 
there in the South B-)

Regards,

Alan.