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

[Jim Fulton]

Phillip J. Eby wrote:
> 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.

That's a fair point.  I suggest it is something to consider in a
later rev of the PEP, but I don't think it alone would justify
a later rev.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org