[Web-SIG] Reviewing WSGI open issues, again...
Phillip J. Eby
pje at telecommunity.com
Thu Sep 9 18:31:27 CEST 2004
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.)
More information about the Web-SIG
mailing list