<div class="gmail_quote">On Sun, Mar 29, 2009 at 5:10 PM, Robert Brewer <span dir="ltr">&lt;<a href="mailto:fumanchu@aminus.org">fumanchu@aminus.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi all,<br>
<br>
We had a good second meeting and answered more issues. My understanding<br>
is that there is another BoF scheduled for tomorrow (Sunday). Check the<br>
Open Space board for details.<br>
<br>
Those present at the second meeting:<br>
<br>
 * Mark Ramm (TG)<br>
<div class="im"> * Mike Orr (Pylons)<br>
 * Bob Brewer (CherryPy)<br>
 * Ian Bicking (Paste, etc)<br>
</div><div class="im"> * Alan Kennedy (WSGI gateway servlets/Jython)<br>
</div> * Rick Copeland (TG)<br>
 * James Bennett (Django)<br>
 * Gary Poster (Launchpad)<br>
 * Chris McDonough (Zope, repoze, etc)<br>
 * Garrett Smith (async WSGI server and middleware)<br>
 * Kumar McMillan (Pylons)<br>
 * Alex Morega (WSGI user)<br>
 * Andrew Sawyer (lurker)<br>
 * Marcus Cavanaugh (Pylons)<br>
 * David Reed (used to be Twisted.web2 maintainer)<br>
 * 8+ others, mostly lurking<br>
<br>
<br>
Revisited Topic: Unicode values in the WSGI environ<br>
---------------------------------------------------<br>
<br>
Consensus: Response status and headers MUST BE unicode. Doing otherwise<br>
(handling both unicode and byte string) would unnecessarily complicate<br>
the construction of middleware components. Origin HTTP servers MUST<br>
decode these to the appropriate bytestrings (all ISO-8859-1?) before<br>
writing them out to the socket.<br>
<br>
<br>
Revisited Topic: wsgi.input<br>
---------------------------<br>
<br>
I raised the issue that, if wsgi.input were an iterable, many apps would<br>
just have to take the extra step of wrapping it in a file-like object<br>
anyway to pass to cgi.Fieldstorage. Others reopened the desire to allow<br>
the app to determine the size of each read().<br>
<br>
We didn&#39;t reach consensus, IMO. Alan argued for an iterable to more<br>
easily support asynchronous servers.</blockquote><div><br></div><div>+1 on the iterator, although I might just like the idea and might be missing something important.  It seems like there are a lot of powerful things being developed with generators in mind, and there are some nifty things you can do with them like the contextlib example:  <a href="http://docs.python.org/library/contextlib.html#contextlib.closing">http://docs.python.org/library/contextlib.html#contextlib.closing</a></div>
<div><br></div><div>Glad to hear a wide range of people showed, even a Django person :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> The counter-argument was that<br>

servers could use non-blocking sockets to allow apps which read() to<br>
yield in the case of no immediate data rather than block indefinitely.<br>
If a file-like object were retained, it would help to publish a<br>
chainable file example to help middleware re-stream files they read any<br>
part of.<br>
<br>
<br>
Response iterable type<br>
----------------------<br>
<br>
The current spec says &quot;all strings referred to in this specification<br>
must be of type str or StringType&quot;. James asked if this could be<br>
loosened to str-like objects. Perhaps we could replace strict typing<br>
with an ABC requirement? General consensus: -0.<br>
<br>
<br>
Continuing deferred issues<br>
--------------------------<br>
<div><div></div><div class="h5"><br>
 * Lots of little changes: the server&#39;s supported HTTP version,<br>
   file_wrapper edge cases, etc.<br>
 * Python 3, and the scheduling of WSGI improvements<br>
 * Asynchronous WSGI support. Mostly non-existent. Fix it? Fork it?<br>
   Drop it?<br>
 * Lifecycle methods (start/stop/etc event API driven by the container)<br>
 * Remove app_iter.close?<br>
<br>
<br>
Robert Brewer<br>
<a href="mailto:fumanchu@aminus.org">fumanchu@aminus.org</a><br>
<br>
_______________________________________________<br>
Web-SIG mailing list<br>
<a href="mailto:Web-SIG@python.org">Web-SIG@python.org</a><br>
Web SIG: <a href="http://www.python.org/sigs/web-sig" target="_blank">http://www.python.org/sigs/web-sig</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/web-sig/noah.gift%40gmail.com" target="_blank">http://mail.python.org/mailman/options/web-sig/noah.gift%40gmail.com</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Cheers,<br><br>Noah<br>