[Web-SIG] PEP 0333 and PEP XXXX Updated
renesd at gmail.com
Mon Sep 21 13:29:31 CEST 2009
On Mon, Sep 21, 2009 at 11:42 AM, Graham Dumpleton <
graham.dumpleton at gmail.com> wrote:
> 2009/9/21 René Dudfield <renesd at gmail.com>:
> > On Mon, Sep 21, 2009 at 2:46 AM, Robert Brewer <fumanchu at aminus.org>
> > ...
> >> 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.
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.
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
- considering requests as first class objects rather than as function calls.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Web-SIG