[Web-SIG] Re: Bill's comments on WSGI draft 1.4

[Alan Kennedy]

[tony at lownds.com]
> Which do you think is better? That servers should understand file objects
> as return values, or that applications should be careful to wrap files?

I really like the wsgi.file_wrapper solution, because it is neither of 
the above. I see it as the server telling the application how files 
should be wrapped, but in a platform independent way.

I think that Phillip's posted definition of the FileWrapper class should 
be included in the spec, as an example of what is expected. Many server 
authors can just drop that standard FileWrapper definition into their 
code, and all will be well.

Although the definition of the file_wrapper may need to vary between 
servers, the overhead is not large. And any server author who really 
needs to get fancy with file_wrapper's will probably have a very good 
idea of what they are doing anyway.

 From the efficiency point of view, it is important to note that the 
server is free to implement the FileWrapper class in whatever way it 
sees fit, e.g. ignoring the buffer size parameter, or supplying it's own 
optimal default value for the parameter, etc, etc.

Phillip, am I off-base by requesting that there be a 'pathname' 
attribute on file_wrapper instances? Fair enough if the file_wrapper 
gets hidden by some component of the middleware stack: in that case the 
pathname loses its meaning anyway because the component has obviously 
transformed the content of the file in some way. In cases where the 
file_wrapper does not wrap an OS file, e.g. sockets, pipes, etc, the 
pathname could be set/defaulted to None.

One use case for this is, for example, a page templating middleware 
component. While parsing the text of a page template (wrapped in a 
file_wrapper) passed down from higher up the stack, it could use the 
pathname as a starting point to resolve relative pathnames in the page 
template source, e.g. include files, etc. Though it could perhaps be 
argued that the higher-up component should be responsible for resolving 
such relative references, because it is the component which actually 
knows where the template file came from?

Regards,

Alan.