[Web-SIG] WSGI Open Space @ PyCon.

[Robert Brewer]

We had a smaller third meeting and answered more issues.

Those present at the third meeting:

 * Mark Ramm (TG)
 * Mike Orr (Pylons)
 * Bob Brewer (CherryPy)
 * Glyph Lefkowitz (Twisted)
 * David Reid (Twisted)
 * Jean-Paul Calderone (Twisted)

Continuing Topic: string type for PATH_INFO and SCRIPT_NAME
-----------------------------------------------------------

Much discussion on how to safely decode the Request-URI. Several options
were put forth, including schemes where both unicode and bytes are stuck
in the environ. Final rough consensus was that, even though request
headers MUST be unicode in the environ, SCRIPT_NAME and PATH_INFO
probably MUST be byte strings in order to not "guess wrong" about their
encoding. In addition, a new environ key which indicates whether
%2F-slashes were decoded improperly or not would be beneficial.


Continuing Topic: wsgi.input
----------------------------

Glyph: iterable is good; file-like is also OK.

Big issue: need a way for the app to tell the server that it is waiting
on output from some other source, possibly running in the same event
loop.

      _______ Reactor ______
     /                      \
+--------+  +--------+  +----------+
|  IMAP  |==|  App   |==|  Server  |
+--------+  +--------+  +----------+

Yielding an empty string (as WSGI 1.0 does) does not provide enough
information; the app needs a way to yield a token which tells the server
"don't call my next() method again until my other source has given me
more input on which to operate."


Asynchronous WSGI support
-------------------------

Mostly non-existent. Fix it? Fork it? Drop it? Glyph seemed to think
we're really close if we fix wsgi.input.


Response value type
-------------------

Glyph suggested as the response tuple grows (e.g. by adding a "close"
method), we should more consider returning an object with .status,
.headers, .body, and .close attributes. Packing/unpacking tuples becomes
tedious. Everyone agreed. If changing to an object is not possible, then
a tuple should not have a variable length; that is, no members would be
optional. Returning a dict would be another option (which would allow
optional keys).


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 (version roadmap)
 * Lifecycle methods (start/stop/etc event API driven by the container)


Robert Brewer
fumanchu at aminus.org