On Mon, Sep 21, 2009 at 11:42 AM, Graham Dumpleton < graham.dumple...@gmail.com> wrote:
> 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. > > Hi, What are you suggesting? Do you have a preference yet? > > 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 > As has been shown, async frameworks *can* support wsgi applications with things like greenlets. See the Eventlet library. I think a future spec could include solutions for lots of issues including. - considering async - considering buffer support - considering proxying support - considering lazily transcoding, allowing handling before reading from socket. - considering requests as first class objects rather than as function calls.
_______________________________________________ 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
