[Web-SIG] Getting back to WSGI grass roots.
pje at telecommunity.com
Wed Sep 23 21:32:05 CEST 2009
At 02:43 PM 9/23/2009 +1000, Graham Dumpleton wrote:
>Sorry, after having had a bit of think while eating lunch, I am going
>to throw up another point of view on this whole issue. So, sit back
>and be just a little bit concerned.
>WSGI stands for Web Server GATEWAY Interface.
>My understanding is that right back at the beginning WSGI was purely
>intended to only be used at the direct interface with the underlying
>web server. This is why I understand, in part at least, the term
>'gateway is used in the acronym.
This is incorrect. WSGI's roots are in an interface that was used
inside of PEAK applications, as a way of connecting components, and
allowing pieces from different frameworks to be combined in a single
application, while also being able to run under CGI or FastCGI or a
dedicated server. That interface was basically a CGI-like
environ/stdin/stdout/stderr, represented as function call arguments.
The original terminology in the December 2003 draft used the term
"container" as a catchall, rather than distinguishing servers from middleware.
>The problem was that people discovered one could apply the same
>interface for use as middleware. As we all know, that has been used
>quite successfully, but has also been equally abused.
People didn't "discover it" - the term first appeared in the second
draft of the spec, and was part of the idea before I ever wrote the
first posting to the Web-SIG; I just didn't use that word.
>By seeing WSGI as being layers instead, first thing is that web
>frameworks such as web2py and CherryPy which merely use WSGI as the
>gateway interface would continue to work directly on this layer,
>regardless of whether they use Python 2.X or 3.X. Those frameworks are
>already going to translate what ever this interface defines into their
>own internal interface and effectively relegate WSGI from any higher
>levels of the application.
>We now get back to the unicode vs bytes argument we have been having.
>This argument will not vanish by virtue of doing this, but instead of
>pushing the unicode translation down into the gateway interface layer,
>we just apply it on top.
I don't understand what you mean by "layers" here.
>To avoid conflict, one could as a minimal measure just add an
>additional 'wsgi.' variable which indicates whether interface is
>'bytes' or 'unicode' and hope middleware validate they have been
>plugged in at the correct level.
Dear please God, no.
>Anyway, that is the thought. Should we be looking at WSGI as a set of
>layers instead of assuming we have to push unicode into the gateway
These are not mutually exclusive options. However, the set of layers
thing, if I'm understanding it correctly, is a big fat -1000 --
totally invalidates the whole point of WSGI. Honestly, I don't even
like having two versions of the spec, which is why the idea of having
a "3.0" really ticks me off. Standards don't benefit from having
multiple versions, even in disguised forms like "layers" or "options".
>FWIW, I thought of this because I was going to suggest at this point
>that overall we have a break from the discussion at this point.
I'm not sure I follow you. Ian has put forth a proposal that I
heartily support, with the possible exception of a part that I've
asked for clarification on. Others have expressed support for that
proposal as well, and I haven't seen any -1's on it yet.
Perhaps you should take a look at it? (It's under the "Proposal to
remove SCRIPT_NAME/PATH_INFO" thread, but it's really a complete
proposal for moving forward with a single new 2.0 spec.)
More information about the Web-SIG