[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