[Web-SIG] Standardising containment.

[Ian Bicking]

Alan Kennedy wrote:
>  > Of course, there is an issue -- if not a file, it would be nice to find
>  > the terminal application for a particular URL.  But that's very vague,
>  > and something that WSGI does not facilitate.  If we have a bunch of
>  > middleware, is there any way to say "give me the last one"?  Is that
>  > even meaningful, as the middleware is not necessary pass-through?  So
>  > maybe if you think you need the terminal application, it might be better
>  > to reconsider and refactor the problem.
> 
> I'm not sure I see a direct connection between the terminal application 
> and uri->file mapping.
> 
> Another example that springs to mind is a middleware component that 
> takes care of, say "media downgrading", i.e. removing image references 
> for aural/tactile/textual user-agents, and replacing it with a 
> textual/metadata equivalent.
> 
> Such a component may not live at the top of the middleware stack. Quite 
> possibly some higher up component will be generating some form of 
> markup, which contains image references. The rendering component, 
> further down the stack, would rewrite those references in the markup to 
> contain whatever textual equivalent is appropriate.
> 
> Now, when the downgrading component is doing it's job, simply knowing a 
> URI reference to each image may not be enough. If it is going to 
> transform a reference to an image, it may need to actually find, open 
> and parse that image, in order to extract it's metadata, e.g. width, 
> height, textual description, etc.

This is reasonable.  My initial suggestion would be to create an 
artificial request; creating a new environ and re-calling the 
application, fetching the object at that location.  Then, if it is a 
file object you can find it on disk (file objects have some attribute, I 
forget what), or if not you can read the data in and find its width and 
such.  But that might not work...

> Let's further assume that requests for the images URIs are *not* handled 
> by a WSGI component. Let's say for example instead that URIs for such 
> static asset files are served by the platform (e.g. Apache) directly, 
> for (perhaps dubious, perhaps valid) performance reasons.

Obviously, this is much more complex, as the middleware can't call its 
application, since the application doesn't actually have access to the 
object, rather some parent server handles the object.

If you wanted to do the same sort of recursive request, a server could 
provide an extension to allow this.  Presumably you would get back 
another iterable, which may be a file object, which would contain the 
necessary information.

But, in both cases, there's a limit to what you can do -- you only get 
access to the public information stored in that particular image.  Maybe 
there's text files alongside the image, which mean that you need access 
to the filename.  E.g., image.jpg and image.jpg.desc, in the same 
directory.  If you get back the original file object, you can do this -- 
but it seems likely in many circumstances that you won't get back the 
file object at all, you'll get some wrapped version, and you won't be 
able to find the filename.

This is also where it would be nice if the response had more structure 
(or at least potential for structure) than what we currently have in 
WSGI.  If there were an (optional) attribute .fileobj (or something) 
wrappers could use this to expose the underlying file object, useful 
when you want to do this kind of server introspection.  It's not 
impossible that the application iterator could have these methods, but 
it's not an extension that WSGI really talks about.  Maybe it should.

Another extension that a server could implement is a URL resolver; if 
the server actually resolved URLs, to applications/resources/files, then 
it might expose this.  But as an extension it's not uniform, and I don't 
think it could be very uniform.  But I think there's a genuine need 
there, as I encounter things like this myself.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org