[Web-SIG] WSGI Open Space @ PyCon.

[Robert Brewer]

Hi all,

We had a good second meeting and answered more issues. My understanding
is that there is another BoF scheduled for tomorrow (Sunday). Check the
Open Space board for details.

Those present at the second meeting:

 * Mark Ramm (TG)
 * Mike Orr (Pylons)
 * Bob Brewer (CherryPy)
 * Ian Bicking (Paste, etc)
 * Alan Kennedy (WSGI gateway servlets/Jython)
 * Rick Copeland (TG)
 * James Bennett (Django)
 * Gary Poster (Launchpad)
 * Chris McDonough (Zope, repoze, etc)
 * Garrett Smith (async WSGI server and middleware)
 * Kumar McMillan (Pylons)
 * Alex Morega (WSGI user)
 * Andrew Sawyer (lurker)
 * Marcus Cavanaugh (Pylons)
 * David Reed (used to be Twisted.web2 maintainer)
 * 8+ others, mostly lurking


Revisited Topic: Unicode values in the WSGI environ
---------------------------------------------------

Consensus: Response status and headers MUST BE unicode. Doing otherwise
(handling both unicode and byte string) would unnecessarily complicate
the construction of middleware components. Origin HTTP servers MUST
decode these to the appropriate bytestrings (all ISO-8859-1?) before
writing them out to the socket.


Revisited Topic: wsgi.input
---------------------------

I raised the issue that, if wsgi.input were an iterable, many apps would
just have to take the extra step of wrapping it in a file-like object
anyway to pass to cgi.Fieldstorage. Others reopened the desire to allow
the app to determine the size of each read().

We didn't reach consensus, IMO. Alan argued for an iterable to more
easily support asynchronous servers. The counter-argument was that
servers could use non-blocking sockets to allow apps which read() to
yield in the case of no immediate data rather than block indefinitely.
If a file-like object were retained, it would help to publish a
chainable file example to help middleware re-stream files they read any
part of.


Response iterable type
----------------------

The current spec says "all strings referred to in this specification
must be of type str or StringType". James asked if this could be
loosened to str-like objects. Perhaps we could replace strict typing
with an ABC requirement? General consensus: -0.


Continuing deferred issues
--------------------------

 * Lots of little changes: the server's supported HTTP version,
   file_wrapper edge cases, etc.
 * Python 3, and the scheduling of WSGI improvements
 * Asynchronous WSGI support. Mostly non-existent. Fix it? Fork it?
   Drop it?
 * Lifecycle methods (start/stop/etc event API driven by the container)
 * Remove app_iter.close?


Robert Brewer
fumanchu at aminus.org