[Web-SIG] a possible error in the WSGI spec

[Phillip J. Eby]

At 09:36 AM 12/27/2007 +1100, Graham Dumpleton wrote:
>Due to this inactivity at least, some I guess would like to see the
>1.1 specification created or at least an amendment to 1.0 to at least
>adjust points in the original specification that were in hindsight
>wrong or impractical, plus allow for Python 3.0. It is a silly
>situation to have that many if not all WSGI adapters in existence are
>not even strictly in compliance with the specification.

I'd love it if somebody would be so kind as to distill a summary of 
the points that need to go into a 1.0 errata/clarifications document, 
and I would be happy to update the PEP (and perhaps make it Final, at 
long last) following discussion and consensus where possible, 
pronouncement where not.

I don't think a 1.1 is *necessarily* required; most of the issues 
that might make a 1.1 desirable may be better handled via a 2.0, and 
getting some closure on the issues that *can* be closed for 1.0 could 
be a good place to start that process.


>Otherwise I can't really see much happening with it as it appears that
>everyone is waiting for you to carry it forward from here.

I've been thinking, actually, that the best way to get the WSGI 2.0 
ball rolling would be to write some code.  Given that 2.0 is intended 
to make writing apps and middleware simpler, it would make more sense 
for its design to be driven by somewhat more aesthetic 
considerations.  Also, we have the ability now to take any of the 
large body of WSGI 1.0 code and see what it would look like under 
2.0, so we can be less theoretical as well.

At the same time though, finishing 1.0 will be a good start to 
2.0.  I want it to be utterly trivial for a 2.0 app to run under a 
1.0 server, and *possible* to run 1.0 apps under a 2.0 server, with 
some potential restrictions.  (A 1.0 app that uses write() calls 
would require either buffering -- which technically violates the 1.0 
spec -- or threading, or greenlets, in order to run under 2.0.)

So, having the hairy bits of 1.0 fully nailed down, and having a list 
of what bits we know cause trouble and would like to change, would be 
good to know before trying to create a formal spec.

Informally, OTOH, playing with 2.0 prototypes should be pretty 
informative, too.