[Web-SIG] WSGI 2

[Mark Ramm]

> Personally I don't believe we should be trying to support async
> servers in the WSGI specification. Leave it simple and cater for the
> predominant case rather than make it complicated just to support what
> is going to be a minority deployment. It was async servers that got
> the whole discussion derailed last time. Leave input stream as is now
> as it is a known quantity and shown through actual use to work
> acceptably. Changing to an input iterator in my mind introduces too
> many unknowns around how input buffering is going to behave. In worst
> case you could really screw up performance because of a trickle of
> input coming into an application where no way for an application to
> control block size of what is read.

Yea, someone at work suggested that we should read from the input in a
file like way, and include a little chained file implementation in
wsgi ref, or just point to it in the spec, so people can read the
first 1000 bytes off of the input, and then pass along what they read,
plus the rest of the file in a way that's transparent to the
underlying application.   Makes good sense to me, and I'm pretty sure
I can find Rick's ittertools.chain inspired chained file
implementation.

--Mark