[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