[Web-SIG] WSGI adoption
py-web-sig at xhaus.com
Thu Nov 25 23:50:10 CET 2004
> 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.
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-)
More information about the Web-SIG