[Web-SIG] WSGI Open Space @ PyCon.
alan at xhaus.com
Thu Apr 2 01:43:32 CEST 2009
> +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:
Indeed, like coroutines.
>> 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.
Ah, but the problem with that is that one can't magically suspend
methods like that and return control to the scheduler, without using
coroutines or stackless.
Who does the read() method return control to when there's no data
available (i.e. no bytes on the socket). If wsgi.input is a simple
file-like object, then it's methods must be coded to recognise, rather
than blocking, when the data is not yet available to fulfill the
applications expectation. How does it know how to return control to
the scheduler, instead of the application?
If the application expects to receive all of the data that it asked
for with a, say read(1024) call, it has to be prepared to accept that
it may get less than 1024 bytes, in an asynchronous situation. What
does it return to the application in the case when < 1024 bytes is
>> 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.
I don't think that re-streaming of input should be a part of the spec;
it's an application layer thing. We don't expect to re-stream the
output of an application: why re-stream the input?
If some application needs to examine the entire byte sequence for
whatever reasons, that's a special case that can be catered for with
itertools, and dedicated middleware.
>> Continuing deferred issues
>> * Lifecycle methods (start/stop/etc event API driven by the container)
I'd really like to get this one nailed: java people and .net people
expect this stuff.
More information about the Web-SIG