[Web-SIG] Standardising containment.

Paul Boddie paul.boddie at ementor.no
Mon Sep 6 17:00:09 CEST 2004


Alan Kennedy wrote:
> 
> [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.
> 
> 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.

Perhaps WSGI is too "low-level" for such considerations. I don't know.

> In the *general* case, yes, such a mapping has no meaning.
> 
> But there are specific cases, e.g. static file serving, where it is 
> required.

Coming from a J2EE background, as I guess you are, there's a fairly
strong
tradition that resources are sort of "mounted" within the context of the
application, isn't there? In other words, if my application refers to
somedir/somefile, the framework will have done the necessary directory
changing such that the reference translates to
$CONTEXT/somedir/somefile.

It actually doesn't matter what the URL is and whether you're mapping
that
or something else to a filename, or whether you're mapping anything to a
filename at all. It could just be a nice idea to define the behaviour
when
some component uses a non-absolute path in order to access some
resource.

[__file__]

> And that is a nice (python-specific) solution to the problem.
> 
> Perhaps it's worth adding something to the Q&A about how to map URIs
to 
> files in the local file system, based on the above pythonic, i.e. 
> module.__file__, approach?

I've seen some strange stuff with __file__ in my time, however.
Moreover,
how does all this map to things like Zope where resources aren't
necessarily
related to the filesystem?

Paul


More information about the Web-SIG mailing list