[Web-SIG] Standardised configuration and temporary directories.
paul.boddie at ementor.no
Mon Sep 6 10:16:29 CEST 2004
Alan Kennedy wrote:
> While thinking about writing middleware, two issues occurred to me
> may need to be addressed in the WSGI spec.
> 1. Temporary storage/scratch directory.
I've been thinking about this at the level above frameworks, and I do
how far up in the applications stack this information would remain
If you consider something like Zope, I think the only place where this
of thing is exposed to applications is in the machinery around file
but I don't necessarily think you'd want applications directly
with such directories.
That said, for both applications and frameworks, it is interesting to
concepts such as shared and private storage, and at a low enough level I
imagine that things like temporary directories are relevant. (It is
shocking to see what cgi.FieldStorage does with temporary files, I might
> 2. Standardised parameter configuration and specification.
As you've said, various frameworks provide mechanisms for specifying
parameters, yet this means that there isn't a single method of
administration for developers or users who don't care enough about those
frameworks to know how to deal with them all. I'm inclined to think that
better tools could be the answer here - if you have a simple
file reminiscent of Webware's .config files (which are Python modules
simple dictionaries or attributes) then different tools could produce
.conf files or Java Servlet web.xml files, for example.
> I'm still not sure about having such a standard configuration
> or how such a thing would be presented inside the WSGI environment.
> it does seem to me to be an area that needs addressing.
I've avoided this issue with WebStack so far, mostly because the
configuration done at the adapter level (the glue code between
and WebStack applications/frameworks) mainly covers things like the
port number and other things that aren't particularly interesting at
levels. Moreover, applications can often be configured through things
modules acting as configuration files, and such things are clearly
from issues of framework configuration.
More information about the Web-SIG