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