[Web-SIG] Returned application object and fileno.

[Alan Kennedy]

[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.

I'm trying to come up with a scheme whereby applications can do those 
things transparently across cpython, jython and ironpython. So when I 
said "I'm not sure I understand", I should have said "I don't understand 
how your proposed os_file() or os_stream() approach would work, without 
forcing application authors to detect the platform they are running on 
and alter their applications behaviour accordingly".

> Under CPython, the server could use something like sendfile() or epoll() 
>  to transfer data, if it has access to the underlying file descriptor.
> Under Jython, with a server written in Java, it would be nice to allow 
> the use the most efficient Java mechanism to transfer data from the file 
> to the client, which I guess is the functionality under java.nio. To do 
> this, the server would need to access the underlying Java object 
> representing the file, a java.nio.Channel or similar.

Precisely: maximizing efficiency is high on my priority list.

As a datapoint, using java.nio.Channel would currently not be possible 
under most existing J2EE containers, since they tend to use the old 
java.net APIs for socket creation. Such java.net-created sockets don't 
have java.nio.Channel's: you have to use the java.nio APIs to get 
java.nio.Channels.

Which will be a breeze pythonistas when I'm finished my jynio modules, 
e.g. non-blocking support for jython: e.g. select, asyncore, etc, which 
is completely based on java.nio. Hopefully we will then see the cpython 
asynch frameworks, e.g. Medusa, Twisted, etc, running on java as well. I 
would then expect to see some serious performance competition between 
cpython and jython, especially since jython is not restricted by a GIL.

Regards,

Alan.