On 27/12/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 04:15 PM 12/26/2007 +1100, Graham Dumpleton wrote: > >On 26/12/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > > > At 12:28 PM 12/24/2007 +0100, Manlio Perillo wrote: > > > >By the way: isn't it better to first release a WSGI 1.1 before > > > >jumping to a (incompatible) WSGI 2.0? > > > > > > Better for whom, and for what purpose? > > > >As has been pointed out before, the main discrepancy known of is the > >definition of readline() on wsgi.input. Don't know of anything that > >implements it per the specification because if it was written per the > >specification then cgi.FieldStorage wouldn't work. > > > >The other more recent issue is how to interpret the WSGI specification > >for Python 3. > > > >Personally I don't think it is sufficient that the only mention of > >these issues is in the archives of the mailing list. Even if you > >personally don't want a version 1.1 specification, would you consider > >an official addendum to the 1.0 specification with it being at least > >posted on www.wsgi.org if the PEP itself can't be amended. > > These are good things to have, sure. But this doesn't answer the > question of why doing that first would be *better* than doing 2.0 > first, assuming that there is any reason why they can't or shouldn't > be worked on concurrently.
Because your name is on the WSGI PEP, people tend to look to you to take a lead on things rather than cross you and do it in your absence. The WSGI 2.0 specification has been brought up before on a number of occasions and although a number of discussion points have been brought up, it is effectively dead in the water and nothing is happening. If you were to take the ideas for WSGI 2.0 on board and push forward with it as most seem to be expecting, then maybe jumping to 2.0 could happen, but it isn't. 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. If there is never going to be a 1.1, then maybe we should start a campaign to force all developers of WSGI adapters to modify their code to make it 1.0 compliant. If that then means that most of the Python web frameworks then no longer work, then so be it, after all, they can't be WSGI compliant either if that is the case. Now, if you feel that you aren't really the BDFL for the WSGI specification then clearly state that and let us get on with setting up a proper community process, including some form of voting and oversight mechanism to herald the development of the WSGI 2.0. 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. Graham _______________________________________________ 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
