[Web-SIG] Getting back to WSGI grass roots.
graham.dumpleton at gmail.com
Thu Sep 24 03:47:40 CEST 2009
2009/9/24 P.J. Eby <pje at telecommunity.com>:
>> 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".
This isn't really about multiple versions of the specification which
shows you do perhaps simply don't understand. With such a negative
response, seems no point in trying to explain to you though.
>> 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.)
I have read it. Right now there is a mere 10 posts in that discussion
which is nothing compared to the scrutiny that other proposals have
got. Other proposals have also had Armin and Robert trying out actual
code to either implement them or investigate the practicality of them
actually working. I have seen no suggestion that this has been done in
regard to Ian's proposal, so it is theoretical only whether other
options have at least been tried to an extent.
Putting aside the technical merits or otherwise of Ian's suggestions,
it falls at a time akin to how governments will introduce new
legislation very late in a sitting (ie., 3am) in the morning, when
most have lost interest or don't care any more. The governments do
this because they know it will not get the scrutiny it should. Now, I
am not saying that Ian has done that deliberately, just that it has
been unfortunate timing in that some of the participants in the
discussions seemed to have faded away and at this point most are
possibly just seeing this as all part of the original discussion
instead of something new and so either not commenting or simply cant
be bothered commenting.
With that in mind, part of what I suggested was for us all to take a
breather and try and get together some concise documentation on a web
site somewhere, along with working code examples for all the different
options, that can sit on top of existing WSGI implementations so that
people can actually try out and experiment with the options and see
what in practice works. This way people can see exactly what is being
suggested rather than having to wade through huge amounts of emails to
distil what is important and what isn't. Don't know why you didn't
understand what I was suggesting in that part of my email.
Anyway, I am at the point that if someone else wants to do that, ie.,
document the proposals and provide example implementation code that
will run on top of WSGI 1.0, they can, but frankly I am not sure I can
be bothered now even though I suggested it.
Overall, I believe I have more or less worked out what I will probably
now do in regard to mod_wsgi and its future, and that decision will
mean I no longer have to care about what you all decide as I wouldn't
necessarily have to implement it anyway. I'll be talking to a few
others off list about if first and then make my final decision. After
almost two years of trying to get WSGI for Python 3.0 to fly, I really
do think it is time for me to give up. I did say a while back I would
try one last push and this has been it.
More information about the Web-SIG