[Web-SIG] PEP 444 != WSGI 2.0

[Alice Bevan–McGregor]

>>> "After some discussion on the Web-SIG mailing list, PEP 444 is now 
>>> "officially" WSGI 2, and PEP 3333 is WSGI 1.1"

This out-of-context quote came after prior discussion of PEP 444 (and 
clear statements of draft-ness) throughout a rather excellent thread on 
HTTP server performance.

The majority of the quotes I find on the CherryPy and WebPy mailing 
lists are better worded: "...updated version of PEP 444[1] is availble 
in draft form", "...[m.s.http] supports PEP 444 (with modifications) 
and, soon, my draft rewrite" and "...PEP 444, I'm trying as hard as I 
can to get my rewrite polished" show up in a quick search.

Apologies for the confusion.

> I'm guessing that Graham is concerned that Alice's assertion implies 
> that the PEP is approved.

He has also raised concerns over my fundamentally not having a mandate, 
having not been granted control over anything, etc.  For completeness 
sake, here's a link to the beginning of the thread in his blog comments:

	http://bit.ly/htHLAz

>> OTOH I agree with Ian that it seems correct to say that PEP 444 (which 
>> is still under development) is striving to arrive at a consensus for 
>> what will be named WSGI 2.0. This is not unusual in the world of 
>> standards -- future standards usually are given names and document IDs 
>> long before there is agreement on the contents of the standard. In this 
>> sense Alice's use of "officially" is not incorrect, although out of 
>> context it could be misunderstood to imply PEP approval. I would 
>> recommend adding caution about this whenever the equivalency between 
>> PEP 444 and WSGI 2.0 is mentioned -- perhaps it is enough to state that 
>> "PEP 444 is the draft for WSGI 2.0".
> 
> I'd suggest that that is even too strong. You are giving the impression 
> that no one else can separately come up with another proposal, 
> especially one that is significantly different.

People have been referring to "anything beyond WSGI 1" as "WSGI 2" for 
a long time.  As in, "I'd like to see X in WSGI 2", or "I hope they fix 
Y in WSGI 2", etc.

As it stands, and since you have refused to give evidence towards 
(links to) others working on things they refer to as "WSGI 2", my 
references to PEP 444 as a draft of WSGI 2 are not unreasonable.  
Quotes taken out of context to support your arguments aren't needed.

>> Often people or companies draw premature conclusions from draft 
>> standards and prepare implementations that comply with the draft 
>> standard in the hope that the draft won't change before it is set in 
>> stone, and sometimes such implementations are incorrectly billed as 
>> compliant with the standard (rather than with a specific version of the 
>> draft). I don't know if that is what Alice is doing -- an equally 
>> likely theory is that she's just excited.

Darn tootin' I'm excited.  :D  The only things that depress me in the 
slightest are the lack of current discussion on the Web-SIG list (I did 
post a thread announcing my rewrite and asking for input, but there 
were no takers) and being told (indirectly) that my solution is crap, 
it'll never be adopted, that I'm wasting my time, and wasting everybody 
else's time.

That's not constructive critisizm or technical faults, that's 
attempting to beat someone down with the weight of your opinion.

>> I haven't followed the development of PEP 444 much, so I can't comment 
>> on how much agreement there is on the draft; Ian's use of "alpha" 
>> suggests that there's some way to go still.

There's a long way to go; I don't expect to see even hints of 
ratification in less than 6 months, really.  I have made that clear in 
prior discussions.

>> One clearly factual error in Alice's (quoted) post: PEP 3333 is WSGI 
>> 1.0.1, not WSGI 1.1. AFAIK there's no such thing as WSGI 1.1 now.

Indeed; apologies for that.  On the mailing lists where Graham has 
stepped in and corrected me I've responsed by thanking him and 
confirming that 3333 is, in fact, 1.0.1.

>> Alice, since you have in the past posted here suggesting you are 
>> interested in carrying PEP 444 / WSGI 2.0 forward, please acknowledge 
>> that you understand the concerns raised in this thread.

Guido, I definitely do; and I have attempted to be as careful as I can 
when attempting to stir discussion over the future of WSGI on any forum 
where I mention it.  I may ocasionally slip up and not give the 
appropriately sized warnings, but I do not do so intentionally!

(Up here in the Canadark the government is now mandating 3/4 of the 
pack graphic warnings on cigarette packages; surely discussion over a 
document which clearly states DRAFT in the header don't need to be 
couched in that level of politial correctness!)

I see it as unfortunate, however, that a thread discussing the 
validitiy of PEP 444 going forward with the moniker "WSGI 2" using 
biased out-of-context quotes has spawned more discussion than the 
threads asking for technical input on the spec.

Politics is more juicy than dry techincal documents, it seems.

:(

> That may be too late. Alice and I haven't exactly hit it off well. 
> Using the #webcore IRC channel as the forum to work on it as Alice 
> wants is also totally inadequate.

I asked you to join me on IRC to better voice your technical complaints 
against PEP 444, not to attempt to get into a verbal sparring match.  
IRC is higher fidelity than threads in blog comments and isn't an 
unreasonable request after a comment thread begins to visibly derail.

> It is just not possible to fit into a few lines what takes pages to 
> explain to a level that people can understand. As much as this mailing 
> list has caused seemingly never ending discussions in the past that go 
> no where, it is still the appropriate forum for any discussion.

Then please resurrect my "PEP 444 Draft Rewrite" thread from the 24th 
of Dec (merry x-mas!) and describe the technical faults you see within 
it.  Using the same argument, your blog (and comments system) is a less 
desireable place for discussion than this mailing list, too.

> ... Overall I still see what is being done as more of a band aid 
> solution. The whole thing needs a rethink because even when you patch 
> some things, the design in some areas is arguably broken, eg. 
> wsgi.file_wrapper. Just dropping features or ignoring the fact they are 
> broken isn't the answer though.
> [snip] ... There may also be merit in seeing whether the minimum Python 
> version be increased such that a solution could may use of new language 
> features added since Python 2.3. [snip]

Now I'm sure: you haven't read my rewrite.

> So, what am I saying that isn't being heard, only that I don't want to 
> see a band aid solution. I had hoped to devote a lot more time to all 
> this in the coming year now that I have changed jobs and have more 
> flexibility, but am concerned that it is being taken down a specific 
> path with no ability to change it.

You are free to write your own PEP and attempt to garner wide-spread 
review and adoption.  You are also in a position in which to encourage 
adoption by adding support to mod_wsgi, which is a signifigantly more 
impressive position to be in than my simply having written a 
proof-of-concept HTTP server to test out PEP 444 ideas, no matter how 
efficient or light-weight it may be.

	- Alice.