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

[Phillip J. Eby]

At 01:06 PM 12/21/2005 -0500, Jim Fulton wrote:
>Phillip J. Eby wrote:
>>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().
>
>I guess I'm puzzled how the server can fail to do at least as well
>as the application.  Can you think of a case where an application wants to
>output a file and can do better than a simple fallback iterator provided
>by the server?

Again, file_wrapper was created as an optional hack to allow sendfile() and 
java.nio.FileChannel to work.  It's a little late to go back and make it 
required unless we want to start trying to make a WSGI 1.1 spec.

At this point, it's optional because it was optional and everybody's gone 
and implemented servers that either do or don't comply with the existing 
spec.  We're not really in a position to change the spec without a new 
spec.  About a year ago the SIG consensus was basically, "it's done; 
anything from here on out has to be either a clarification of something 
already decided, or addition of new optional features (like an async API)".

Once that was done, people have been making implementations left and right, 
so it's not fair to go back and make them retroactively noncompliant for 
not implementing an explicitly optional feature.