[Web-SIG] Returned application object and fileno.

[Phillip J. Eby]

At 01:39 PM 9/1/04 +0100, Alan Kennedy wrote:
>[Alan Kennedy]
>>>Hmm, I'm not sure I understand what you are saying here Andrew. The 
>>>use-case we're trying to cover is where the application wants to return 
>>>a file-like object to the WSGI server/framework. The applications 
>>>intention should be that the contents of the file-like object, from the 
>>>current file-pointer onwards, should be transferred to the return socket 
>>>for the HTTP request.
>
>[Andrew Eland]
>>The intent, I think, is to special-case the sending of static files, 
>>allowing a server to use the most efficient method of transferring data 
>>from a file to a socket that the platform provides.
>
>Agreed that special-casing static files for performance reasons is a good 
>thing.
>
>But we also need to consider what happens when the application returns, 
>for example, a StringIO.StringIO, or a gzip.GzipFile.

No, we don't.  WSGI does not support that.  You must return an 
*iterable*.  As Andrew says, 'fileno()' was added to allow special-casing 
operating system file descriptors on platforms that have them, and have 
APIs like 'sendfile()' that can copy data directly from one descriptor to 
another.

If you would like to support special Java stuff, or CLR stuff, you can 
always have your server look for some other attribute name and support that 
as a platform-specific, optional extension for higher performance.

But that's *all* the 'fileno()' support is: a *platform-specific* *optional 
extension* to boost performance in certain cases.  The server isn't even 
required to *check* for a fileno attribute, and the application certainly 
isn't required to provide it.

The application is required to return an iterable.  That's the 
protocol.  You want to return a "file-like" object, you *must* wrap it in 
an iterable of some kind.  For example:

     return [some_io.getvalue()]

is a perfectly reasonable way to return a StringIO.