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

[Ben Sizer]
 >>I thought that one of the major features of most of these Python web
 >>frameworks is that a URI doesn't map to a file but to an object or a
 >>function, several of which might be in one physical file. Since WSGI
 >>seems to be promoted as a minimal system that applies equally to
 >>almost any system, I'd think that such a mapping falls entirely out
 >>of its scope.

[Paul Boddie]
 > It probably does for WSGI, although I wonder how such issues (and the
 > many others out there) can be simultaneously avoided and yet
 > anticipated by the specification in order to avoid incompatibilities
 > later on.

And avoiding incompatibility is what I am trying to do.

[Ben Sizer]
 >>I agree that it might be useful to have this functionality. I think a
 >>standard way to map URIs to Python files would be beneficial for Python
 >>web development. I just don't see it fitting into what people here
 >> have told me about WSGI.

[Paul Boddie]
 > I suppose that Alan is moving slowly up the stack.

I'm sorry if I appear not to be as au fait with these matters as you. I 
see that you've been addressing all of these problems for years with 
WebStack.

 > It's an interesting issue that existing frameworks have addressed
 > in their own ways (the getRealPath that Alan mentioned, Webware's
 > getServerSidePath, and so on), and although one can wonder whether
 > application data (which the image example could almost be considered
 > as being) should be configured within or with reference to the server
 > environment or not, if you consider having to specify the filenames
 > of resources within an application, it's much nicer to be able to
 > make those filenames relative to some deployment variable (eg. where
 > the application ends up when deployed) and to keep those resources
 > bundled with the application than to have to manually configure the
 > application to use absolute paths before/during/after deployment.
 >
 > I hope that made sense. ;-)

Yes, it does make sense.

To summarise: it is *sometimes* the case that static resources and the 
functionality that renders them are *deployed* together, i.e. in the 
directory structure, which can make for simplicity of deployment and 
administration.

And as Phillip has suggested, the python module.__file__ attribute can 
be used to support location of such resources.

Regards,

Alan.