[Web-SIG] Reviewing WSGI open issues, again...

[Phillip J. Eby]

At 05:01 PM 9/9/04 +0100, Alan Kennedy wrote:
>[Phillip J. Eby]
> > * File-like objects -- I think anything we offer for file-like objects
> > should be optional.  The big question is whether to offer a single,
> > introspection-based extension for all file-like things, or whether to
> > use separate extensions for different sorts of things, like
> > 'wsgi.fd_wrapper' for file descriptors and 'wsgi.nio_wrapper' for Java
> > NIO objects, etc.  Does anybody have any arguments/use cases one way
> > or the other?
>
>Optionality is fine by me.
>
>But I don't understand what reasons there might be to have separate class 
>names per platform?
>
>It's always been my understanding that the intention for this capability 
>is so that applications can give "hints", to servers that support 
>high-performance methods of file transmission, that the resource being 
>returned is a candidate for bulk transfer. So, as an application author, 
>I'll surely want that hinting process to work on as many servers as 
>possible, regardless of the platform.

You may want that, but it's going to be platform-dependent whether you can 
do that.  A trivial example: Java doesn't have file descriptors, so you're 
not going to be able to use 'sendfile()' in Java.  So, what's the point of 
having 'fd_wrapper' available there?

>So, if there is a choice of multiple such hinting processes, and I have to 
>look for each one of them at runtime, my code is longer and less efficient 
>than it could be, e.g.
>
>def app_object(environ, start_response):
>   start_response('200 AuQuay', [ ('content-type', 'x-humungous-pdf') ] )
>   result = open('humungous.pdf')
>   for cname in ['fd','nio','dotnet','stackless','pypy','smalltalk']:
>     try:
>       return environ['wsgi.%s_wrapper' % cname](result):
>     except KeyError:
>       pass
>   return result
>
>Instead, if a single class is used, the definition of which is different 
>per server, then I have only to look at that one class.

An object that works with 'fd' isn't going to work with 'nio', or vice 
versa is it?  Or am I missing something about how nio works?

I suppose the alternative is to specify 'wsgi.file_wrapper' such that it's 
required to always return *something* usable, even if it can't figure out 
any way to optimize it.  Objects passed to 'file_wrapper' would have to 
have a 'read', optionally a 'close', and optionally 'fileno'.  (A Jython 
WSGI server would ignore fileno, of course.)