[Web-SIG] PEP 0333 and PEP XXXX Updated

[René Dudfield]

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>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20090921/8413bc54/attachment.htm>