[Web-SIG] Standardized configuration

Ian Bicking ianb at colorstudy.com
Mon Jul 11 20:57:43 CEST 2005


Lately I've been thinking about the role of Paste and WSGI and whatnot. 
  Much of what makes a Paste component Pastey is configuration; 
otherwise the bits are just independent pieces of middleware, WSGI 
applications, etc.  So, potentially if we can agree on configuration, we 
can start using each other's middleware more usefully.

I think we should avoid questions of configuration file syntax for now. 
  Lets instead simply consider configuration consumers.  A standard 
would consist of:

* A WSGI environment key (e.g., 'webapp01.config')
* A standard for what goes in that key (e.g., a dictionary object)
* A reference implementation of the middleware
* Maybe a non-WSGI-environment way to access the configuration (like 
paste.CONFIG, which is a global object that dispatches to per-request 
configuration objects) -- in practice this is really really useful, as 
you don't have to pass the configuration object around.

There's some other things we have to consider, as configuration syntaxes 
do effect the configuration objects significantly.  So, the standard for 
what goes in the key has to take into consideration some possible 
configuration syntaxes.

The obvious starting place is a dictionary-like object.  I would suggest 
that the keys should be valid Python identifiers.  Not all syntaxes 
require this, but some do.  This restriction simply means that 
configuration consumers should try to consume Python identifiers.

There's also a question about name conflicts (two consumers that are 
looking for the same key), and whether nested configuration should be 
preferred, and in what style.

Note that the standard we decide on here doesn't have to be the only way 
the object can be accessed.  For instance, you could make your 
configuration available through 'myframework.config', and create a 
compliant wrapper that lives in 'webapp01.config', perhaps even doing 
different kinds of mapping to fix convention differences.

There's also a question about what types of objects we can expect in the 
configuration.  Some input styles (e.g., INI and command line) only 
produce strings.  I think consumers should treat strings (or maybe a 
special string subclass) specially, performing conversions as necessary 
(e.g., 'yes'->True).

Thoughts?

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


More information about the Web-SIG mailing list