[Web-SIG] Standardising containment.
py-web-sig at xhaus.com
Mon Sep 6 21:10:03 CEST 2004
>>>> 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.
>> 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.
> 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
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*
2. Phillip has already proposed a pythonic solution: the python
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
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
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 ;-)
More information about the Web-SIG