[Web-SIG] Standardised configuration and temporary directories.

[Paul Boddie]

Alan Kennedy wrote:
> 
> While thinking about writing middleware, two issues occurred to me
that 
> 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
wonder
how far up in the applications stack this information would remain
useful.
If you consider something like Zope, I think the only place where this
kind
of thing is exposed to applications is in the machinery around file
uploads,
but I don't necessarily think you'd want applications directly
interfering
with such directories.

That said, for both applications and frameworks, it is interesting to
define
concepts such as shared and private storage, and at a low enough level I
can
imagine that things like temporary directories are relevant. (It is
almost
shocking to see what cgi.FieldStorage does with temporary files, I might
add.)

[...]

> 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
configuration
file reminiscent of Webware's .config files (which are Python modules
with
simple dictionaries or attributes) then different tools could produce
Apache
.conf files or Java Servlet web.xml files, for example.

[...]

> I'm still not sure about having such a standard configuration
mechanism, 
> or how such a thing would be presented inside the WSGI environment.
But 
> 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
frameworks
and WebStack applications/frameworks) mainly covers things like the
server
port number and other things that aren't particularly interesting at
higher
levels. Moreover, applications can often be configured through things
like
modules acting as configuration files, and such things are clearly
separate
from issues of framework configuration.

Paul