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.)
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
