[Web-SIG] Returned application object and fileno.
py-web-sig at xhaus.com
Wed Sep 1 14:39:46 CEST 2004
>> 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.
> 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
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
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.
More information about the Web-SIG