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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ 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
