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 fuman...@aminus.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
