[Web-SIG] Standardised configuration and temporary directories.
Alan Kennedy
py-web-sig at xhaus.com
Sun Sep 5 23:56:10 CEST 2004
Dear Sig,
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.
It is common in servers and frameworks to provide a particular location
for applications to store temporary files, etc: a temporary directory.
This prevents applications from picking their own temporary directories,
which provides platform independence, security and isolation.
I think that this is a such a common thing that may be worth requiring a
WSGI environment variable for it, e.g. environ['wsgi.temp_dir']
I realise that this could be considered a server specific thing, but
server-specific variables mean lack of portability. Perhaps some
containers will not be able to provide the temporary area: in that case
it is better for the application or middleware to check for
environ['wsgi.temp_dir'] == None than to check for perhaps a dozen or
more possible server variables.
2. Standardised parameter configuration and specification.
When I am plugging middleware into a server, it often has need of its
own configuration. For example, session handling middleware may need to
retrieve the name of file system directory to persist session files
into, or connection details for an RDBMS, etc.
Obviously, such configuration values need to be configured somewhere.
1. It could be done in the middleware source file itself, e.g. in global
variables. However, I really don't like this, since it would mean
changing source files, instead of leaving a standard versioned
distribution untouched and read-only.
2. The session middleware could have its own configuration mechanism. It
would define a standard way for it, and it alone, to be configured, e.g.
it names the location of its configuration file. I think that this also
is problematic, primarily becuase lots of different middleware authors
will pick lots of different ways of configuring their stuff, leading to
platform-specific errors, need for debugging, code rewriting, etc. And I
think that the purpose of WSGI is to help prevent this kind of wheel
re-invention.
A more promising place to put it is in the WSGI environment. The next
two methods are different ways of doing that.
3. It could perhaps be set by another middleware component that is prior
to the session handler in the middleware stack: some form of general
configuration component for example. I like this more than the above
options, because it concentrates configuration into one place.
Or rather two places, because there is also the server specific
configuration file, whose contents actually configure how the server
drives the request through the middleware stack. In my case, that is a
Tomcat server.xml file, where I have several parameters which configure
my wsgi servlet.
4. It could be configured in the server configuration file, e.g. the
Tomcat server.xml with modjy, the Apache httpd.conf with mod_python,
environment variables with CGI, etc, etc. I like this one the most
because it means that there is only one configuration environment to manage.
So, as an example, let's say my session middleware is looking for the
following variables
my_fancy_sessions.cookies
my_fancy_sessions.storage_dir
Ideally, it would be nice to be able to have a standardised way of
specifying these variables in a centralised location. Why? Because when
the middleware authors are writing documentation for their module, they
could write something like
"""
Make sure to set values for the following WSGI variables, in whatever
way is appropriate for your chosen WSGI server.
my_fancy_sessions.cookies = True
my_fancy_sessions.storage_dir = '/var/modjy/session_dir'
"""
So, if I was configuring it to run under modjy, my servlet description
would look something like this
<servlet>
<servlet-name>modjy</servlet-name>
<servlet-class>com.xhaus.wsgi.Modjy</servlet-class>
<init-param>
<param-name>python.home</param-name>
<param-value>C:/jython21</param-value>
</init-param>
<init-param>
<param-name>my_fancy_sessions.cookies</param-name>
<param-value>True</param-value>
</init-param>
<init-param>
<param-name>my_fancy_sessions.storage_dir</param-name>
<param-value>/var/modjy/session_dir</param-value>
</init-param>
</servlet>
A CGI implementation could examine the contents of say a WSGI_ENVIRON
os.environ variable, which might contain
"""
my_fancy_sessions.cookies = True
my_fancy_sessions.storage_dir = '/var/modjy/session_dir'
"""
Etc, etc.
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.
Perhaps a simple solution would be to add wording like the following to
the PEP:
"""
WSGI compliant servers must provide a simple mechanism for users to
place name/value pairs in the WSGI environment, without modification or
transformation. This is to make it easy for users to gather all
middleware (i.e. server-independent) configuration under one centralized
configuration mechanism.
"""
Or maybe I'm off base. Maybe session handling middleware is not the sort
of thing that is meant to be universally portable?
Regards,
Alan.
More information about the Web-SIG
mailing list