[Web-SIG] Getting back to WSGI grass roots.

[P.J. Eby]

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
>interface layer?

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.)