[Web-SIG] PEP 0333 and PEP XXXX Updated

[Graham Dumpleton]

2009/9/21 René Dudfield <renesd at gmail.com>:
>
>
> 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?

Not all conversation about this are occurring on the WEB-SIG list.
There are various side discussions happening more fully exploring the
various suggestions and understanding them. It is being done off the
list as the past has shown that if every detail is discussed on the
list it goes on forever and then just collapses. We are really close
this time and not going to let it fail again.

If people for some reason think that I am going to come up with the
final plan, then you'll just need to wait until I can find time again
to blog about how recent discussions have factored into my view of the
world.

>> > 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.

If greenlets do what I am led to believe, then there shouldn't be a
need then to even have async mentioned in the WSGI specification at
all, as it avoids the whole need for an async API at WSGI interface
level. The underlying web server can use whatever internal interface
it wants and WSGI interface using greenlets could be built on top of
that. There doesn't need to be a standardised interface with that
internal interface as it would be an issue for just that particular
web server.

> I think a future spec could include solutions for lots of issues including.
> - considering async

As I said, if this means some sort of separate API support, it should
be a distinct specification from WSGI, and not a part of it.

> - considering buffer support

Not proven to be of any benefit at this stage. At least show that
buffers can be used as a drop in replacement in existing WSGI
applications and you are part way there. Show performance gains in a
modified versions of an existing WSGI server for typical WSGI
applications, then even better.

So, demonstrate its worthwhile and it could be incorporated, but
likely that only niche pure Python WSGI servers would use them as for
generic WSGI servers, especially those building on non Python web
server or infrastructure, likely not worth the trouble.

> - considering proxying support

Proxying generally requires much lower interaction with underlying
request processing and transfer encoding mechanisms. This will not be
possible with many hosting solutions. Again, may only be practical
with pure Python web servers.

> - considering lazily transcoding, allowing handling before reading from
> socket.

No idea what you are talking about. You would have to explain better.
Do note that the WSGI environment dictionary is a Python dictionary
and can't be replaced with a custom dictionary class type. Thus cannot
directly be made to incorporate advanced functionality and doing so
would make implementation of WSGI middleware likely much more fiddly.

> - considering requests as first class objects rather than as function calls.

Outside of scope for WSGI. WSGI is meant to be a low level interface
between web server and Python web application. Just because people
effectively abused it by using it through all levels of an
application, doesn't mean that features intended to make its use in
core of web applications simpler should be forced into the low level
interface with the web server.

In other words, come up with a specification for request objects and
other stuff if you want, but it doesn't belong in WSGI, but would be a
higher level layer that builds on it.

Graham