2009/9/21 René Dudfield <ren...@gmail.com>: > On Mon, Sep 21, 2009 at 2:46 AM, Robert Brewer <fuman...@aminus.org> wrote: > ... >> I want something in between so I don't have to wait months or years for >> WSGI 2. I want to ship a version of CherryPy with Python 3 support last >> week. > > +1 for wsgi 1.1 *very soon* using the "wsgi.url_encoding" idea Graham > made for unicode.
At this point I would suggest that having 'wsgi.uri_encoding' in WSGI 2.0, as Armin describes, is probably better since the unicode hop is more than what a minor version change really should entail. Having definition #3 as WSGI 1.0 for Python 3.X is also probably just a waste of time and will just confuse. As it was stated by someone, too many versions of things isn't good and WSGI 1.0 as per definition #3 for Python 3.X is one such thing which is unnecessary. > With the next WSGI afterwards being an 'anything goes' spec, which > addresses all other issues and can come later (including async, using > buffers, and every other idea people can come up with). There are no other issues except for dropping start_response(), and async doesn't belong in WSGI. If you want async, then come up with a separate standard. You may well manage some overlap which allows sharing of some small subset of components, but in the main, a component which is blocking will not work on async and a component that uses async features isn't going to work on blocking. Why then would you make a specification overly complicated by trying to handle both when there is little if any mutual benefit. It is also likely that it is going to be hard enough to get people to switch over, so the last thing you want is drastic change. As Armin also points out, one doesn't know where web server technology is going. As such, better off only going as far as WSGI 3.0 as described and then let things settle down. Once that is all firmly in place and working well, than can step back and look at where web serving technology has gone in the mean time. 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
