[Web-SIG] Regarding the WSGI draft

[Ian Bicking]

Responding more generally on this thread; or, more generally, here's 
What The WSGI Means To Me...

It's not so much that you can attach servers and frameworks 
independently.  That's nice, but it's not a huge deal.  WSGI is, to me, 
the beginning of a common language about HTTP requests, a standard way 
to represent that request.  It's not the most awesome, easiest to use 
representation of these objects, but I don't think that's a reasonable 
goal, those qualities are too subjective.  WSGI's request and response 
are what we can manage, trying to make everyone happy.

And it's not so bad, because while it's not featureful, it's *really 
simple*.  That's a decent compromise.  The request is the environment 
dictionary the WSGI defines; the response is the status plus headers 
plus written body plus iterable body.  And it's okay that it's this 
simple, because it's a straight-forward mapping of HTTP with little 
information lost, and HTTP is obviously fairly central to this all.

But even though it's simple and adds no real features, nor does it 
enable anything new, it's still interesting because it gives us a 
standard way of communicating (programmatically).  We don't have that 
right now.  Ben's right, there's a lot of work to be done to make a 
good, simple, Python web development environment.  WSGI makes it 
possible to work towards that goal incrementally and in a distributed 
fashion, without competing.  Right now everyone who develops on a 
framework is competing with everyone developing on some other framework. 
It's just too big of a problem space to have to compete on a large 
scale, with the entire environment being take it or leave it.  But I 
don't think the developers actually *want* to compete, it's just been a 
technical necessity.

So, a bit like Phillip, I think WSGI isn't an end to itself, but it 
could be key in enabling further progress.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org