<br><br><div class="gmail_quote">On Mon, Sep 21, 2009 at 11:42 AM, Graham Dumpleton <span dir="ltr">&lt;<a href="mailto:graham.dumpleton@gmail.com">graham.dumpleton@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/9/21 René Dudfield &lt;<a href="mailto:renesd@gmail.com">renesd@gmail.com</a>&gt;:<br>
<div class="im">&gt; On Mon, Sep 21, 2009 at 2:46 AM, Robert Brewer &lt;<a href="mailto:fumanchu@aminus.org">fumanchu@aminus.org</a>&gt; wrote:<br>
&gt; ...<br>
&gt;&gt; I want something in between so I don&#39;t have to wait months or years for<br>
&gt;&gt; WSGI 2. I want to ship a version of CherryPy with Python 3 support last<br>
&gt;&gt; week.<br>
&gt;<br>
&gt; +1 for wsgi 1.1 *very soon* using the &quot;wsgi.url_encoding&quot; idea Graham<br>
&gt; made for unicode.<br>
<br>
</div>At this point I would suggest that having &#39;wsgi.uri_encoding&#39; in WSGI<br>
2.0, as Armin describes, is probably better since the unicode hop is<br>
more than what a minor version change really should entail. Having<br>
definition #3 as WSGI 1.0 for Python 3.X is also probably just a waste<br>
of time and will just confuse. As it was stated by someone, too many<br>
versions of things isn&#39;t good and WSGI 1.0 as per definition #3 for<br>
Python 3.X is one such thing which is unnecessary.<br>
<div class="im"><br></div></blockquote><div><br><br>Hi,<br><br>What are you suggesting?  Do you have a preference yet?<br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
&gt; With the next WSGI afterwards being an &#39;anything goes&#39; spec, which<br>
&gt; addresses all other issues and can come later (including async, using<br>
&gt; buffers, and every other idea people can come up with).<br>
<br>
</div>There are no other issues except for dropping start_response(), and<br>
async doesn&#39;t belong in WSGI. If you want async, then come up with a<br>
separate standard. You may well manage some overlap which allows<br>
sharing of some small subset of components, but in the main, a<br>
component which is blocking will not work on async and a component<br>
that uses async features isn&#39;t going to work on blocking. Why then<br>
would you make a specification overly complicated by trying to handle<br>
both when there is little if any mutual benefit.<br>
<br></blockquote><div><br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It is also likely that it is going to be hard enough to get people to<br>
switch over, so the last thing you want is drastic change. As Armin<br>
also points out, one doesn&#39;t know where web server technology is<br>
going. As such, better off only going as far as WSGI 3.0 as described<br>
and then let things settle down. Once that is all firmly in place and<br>
working well, than can step back and look at where web serving<br>
technology has gone in the mean time.<br>
<font color="#888888"><br>
Graham<br>
</font></blockquote></div><br><br>As has been shown, async frameworks *can* support wsgi applications with things like greenlets.  See the Eventlet library.<br><br>I think a future spec could include solutions for lots of issues including.<br>
- considering async<br>- considering buffer support<br>- considering proxying support<br>- considering lazily transcoding, allowing handling before reading from socket.<br>
- considering requests as first class objects rather than as function calls.<br><br><br><br>