[Web-SIG] Reviewing WSGI open issues, again...

[tony at lownds.com]

[Phillip]
> I suppose the alternative is to specify 'wsgi.file_wrapper' such that it's
> required to always return *something* usable, even if it can't figure out
> any way to optimize it.  Objects passed to 'file_wrapper' would have to
> have a 'read', optionally a 'close', and optionally 'fileno'.  (A Jython
> WSGI server would ignore fileno, of course.)
>

I like this option. As long as the file_wrapper does not initiate any
actions until the server gets it, the results of file_wrapper can be
opaque to middleware. Other methods might be useful too, for instance,
tell() - if an application passes a file that has been seeked to a certain
point, thats where reading of data should start.

I'm assuming the new "combined" wsgi.file_wrapper key would be optional.
This puts a burden on applications that need to send back data from files,
because they'd need fallback logic if the wsgi.file_wrapper key isn't
present. But that seems better on the whole that putting the burden on
servers, all the time.

-Tony