[Web-SIG] Questions/suggestions on 'wsgi.file_wrapper'

[Phillip J. Eby]

At 11:25 AM 12/21/2005 -0500, Jim Fulton wrote:

>Here are some questions and sugesstions on the 'wsgi.file_wrapper'
>part of the WSGI API:
>
>1. Does this need to be optional?  It seems that it would be
>     easy for any server to provide this, it would be nice for
>     applications to be able to rely in it.

It's intentionally optional because its presence signifies that the server 
can do things *better* than the application, if and only if the object is a 
"real" operating system file or other "special" object.  The only reason 
the spec requires only a "file-like" object rather than an object with a 
valid "fileno()" method, is because somebody wanted to support Jython 
objects wrapping Java sio(?) objects, for a Java equivalent of sendfile().


>2. If the file-like object passed has a close method, wouldn't
>     it be acceptable for the iterator returned by wsgi.file_wrapper
>     to close it when iteration is done?
>
>     I would slightly prefer:
>
>     "It may have a close() method, and if so, the iterable returned by
>     wsgi.file_wrapper must have a close() method that invokes the original
>     file-like object's close() method, or the iterable must close the file
>     when the file-like object's read method returns no data."
>
>     I prefer this because it allows a simple generator implementation of
>     a default wsgi.file_wrapper.

I'm sorry, I don't understand what you're asking for here.  I think maybe 
you have a misunderstanding about why the spec is arranged the way it is 
here.  It is intended to ensure that any middleware between the server and 
the application will be able to treat the wrapper as a valid WSGI 
application return value.  The server is allowed to strip off the wrapper, 
if that's in fact what it receives.  But the wrapper has to be a 100% valid 
WSGI return value, or middleware will get confused.  The server must also 
only do special handling *if* it receives the wrapper as a return value; it 
can't assume that just because you called file_wrapper() that it is going 
to use that handler.

If I understand your suggestion correctly, you're asking to change that in 
a way that disallows early closing, and I don't think that should be 
allowed.  If the file has a close(), any middleware involved needs to be 
allowed to call it.


>3. The server should be allowed to use the file wrapper in a different
>     thread than the one used to run the application. This should be noted.
>     Applications should not return file-like objects that rely on running
>     in the same thread.  This too should be noted.

This seems reasonable to me.  For the actual use cases file_wrapper was 
intended to support (sendfile() and the Java equivalent thereof) this 
should be no problem at all.