Steve Holden <[EMAIL PROTECTED]> 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 / [EMAIL PROTECTED] / http://blog.ianbicking.org -- http://mail.python.org/mailman/listinfo/python-list
