Paul Rubin wrote:
Steve Holden <st***@holdenweb.com> writes:
You can read about it in Philip Eby's excellent PEP at
http://www.python.org/peps/pep-0333.html
I looked at this and I have the impression that it tries to do
something worthwhile, but I can't tell precisely what. The "rationale
and goals" section explains good reasons why it doesn't do various
certain things. What's not explained is what DOES it do. The only
thing I can tell is that it connects to an abstracted web server, and
builds up what looks like traditional CGI variables from the incoming
requests.
It's really meant for web framework developers (as opposed to web
application developers, who use web frameworks). Of course it's a fuzzy
line, and people cross back and forth, especially since most all of it
is open source.
So basically it is what you were thinking -- it's a way to connect a web
server to a web application, for any server or application, including
current servers and applications (not just ones that are developed in
the future). It can be a bit more interesting when you delve into
middleware, which are programs that modify the request before handing it
off to another application. But while that opens up interesting
possibilities (I've used that technique a fair amount in WSGIKit:
http://svn.colorstudy.com/trunk/WSGIKit/ ), but it's not incredibly magical.
Mostly, it's the first forward movement we've had in a very long time,
even if the movement isn't huge. It provides a foundation for further
standardization.
WSGI compliance also has some other potential benefits, like encouraging
environment decoupling, and making mock requests easier to produce and
responses easier to consume. But those are somewhat vague side effects.
--
Ian Bicking /
ia**@colorstudy.com /
http://blog.ianbicking.org 
