[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