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

[Phillip J. Eby]

At 07:32 PM 12/21/2005 -0800, Mike Orr 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().
> >
> >
>
>Allowing a file-like object like StringIO also allows the environment to
>be pickled and sent to another process.  This lets a Python web server
>talk directly to a Python application server using WSGI, rather than
>having to kludge through SCGI and then repackage it to WSGI.  I don't
>know of any web servers that do this yet but it would be a shame to lose
>the capability.
>
>If we require a file object, the environment becomes non-pickleable
>because you can't serialize an open file.  SCGI uses passfd, which
>somehow works, but not on Windows.  If we require .fileno(), one could
>have an object that quickly writes the content to a file and passes that
>fileno, but I don't see what that gains.

I think perhaps you've confused the 'file_wrapper' API with the file-like 
objects in the environment.  The discussion above is about 'file_wrapper' 
objects *returned* by the application, not the input/stderr objects in the 
environment.