[Web-SIG] Standardising containment.

[Alan Kennedy]

[Alan Kennedy]
 >>>> The other main one that springs to mind is how WSGI applications
 >>>> discover the file-system path name that corresponds to an URI.

[Phillip J. Eby]
 >>> *boggle*  Why do you think that URIs have anything to do with file
 >>> paths?  In the general case, they are entirely unrelated.

[Alan Kennedy]
 >> Well, perhaps it's just that pretty much every web
 >> server/harness/framework I ever used has support for mapping URIs to
 >> files. How silly of me to try to apply my experience of other web
 >> systems to WSGI.

[Ian Bicking]
 > I guess it depends how you're looking at it.  Zope, for instance, is
 > exactly the opposite -- files are an extension, not a native concept
 > (with respect to URLs).  Quixote and Twisted both prominently feature
 > ways to parse the URL to find a resource, which is not a file.  At some
 > level, most frameworks allow for this kind of URL manipulation.  And I
 > would assume the same is true in Java, somehow...?  At least among
 > Python frameworks, URIs cannot generally be mapped to URLs.

Just a couple of quick points.

1. I am fully aware that there is not necessarily a mapping from URLs to 
files. It's just that sometimes it does have a meaning, with serving 
static files being the obvious example, and I think we need to keep that 
in mind.

Though perhaps it should remain a server-specific thing. Perhaps it's 
worth adding a note to the spec to explain why such facilities are *not* 
available.

2. Phillip has already proposed a pythonic solution: the python 
module.__file__ attribute.

3. I am *not* holding up J2EE as the be-all-and-end-all of models for 
web development: it has substantial problems, IMO. It's just that A: I 
happen to be implementing a WSGI server on J2EE at the moment, B: it is 
a very mature web architecture that provides a lot of useful facilities. 
I think WSGI should at least be informed by as many such architectures 
as possible, and C: I've used J2EE often enough to know reasonably well 
what it can and can't do.

4. J2EE does not provide particularly good facilities for incrementally 
mapping URL sub-components to application objects, although it does 
provide all the information required should one desire to do so oneself.

 > 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.

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.

So how does the component actually get its mitts on the physical image 
when it is needed? All it has is an URI for the image. It could crank up 
httplib, make an HTTP request to the platform for the image, and examine 
the returned contents. But that's significantly more expensive than 
asking the platform to construct a file-system pathname for the image 
file, based solely on its URI, and then accessing it through the filesystem.

This example is perhaps overly contrived, but I'm trying to explain 
examples of why I think it is sometimes necessary to refer to the 
platform in order to find physical locations of other content served by 
that platform. This other content may not be under the control of WSGI 
applications.

Either way, I think it's a good thing for us to thrash all of these 
issues out. It's better that we sort it out as much as possible now 
rather than after the WSGI PEP has been finalised.

Maybe my approach has been wrong over the last few days. I've been 
writing to the SIG about issues that I have seen during my 
implementation phase. When I write about a particular issue, or feature 
of another language/framework, that doesn't mean that I'm demanding for 
such to be added to WSGI. It just means "Hey Folks, here's something 
that occurred to me that may need some consideration for WSGI".

And judging by many of the responses to my posts, e.g. along the lines 
of "I see what you're saying, *but* .... ", and "Well I think it's 
outside the spec, but yes you're right, it would be really nice to 
standardise X", I seem to be identifying the boundaries of WSGI pretty well.

I'm happy to be shot down by good arguments: we're all trying to achieve 
the same thing here: the best possible pythonic web architecture. And 
I'll never be too old to learn ;-)

Regards,

Alan.