[Web-SIG] Questions/suggestions on 'wsgi.file_wrapper'
jim at zope.com
Wed Dec 21 19:49:48 CET 2005
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 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
More information about the Web-SIG