[Web-SIG] Re: WSGI and Configuration

[Alan Kennedy]

[Peter Hunt]
 > Why don't we just let each middleware/gateway/application handle
 > configuration by itself? Sure, it's a pain, but it's the defacto way
 > to do it.

I disagree.

If we permit "the market" to decide its preferred form of configuration, 
we're going to end up with a babel of configuration file formats.

For example, say that the convention is to configure middleware through 
server/gateway configuration files. Authors of WSGI middleware would 
then have to document how to configure their component in several 
different configuration languages, each of which have subtly different 
quoting, escaping, encoding, etc, issues, for example: Apache httpd.conf 
markup language vs. XML (j2ee, etc)

If the convention is for middleware to decide its own configuration 
format, then building and configuring middleware stacks could 
potentially be an exercise in frustration, maintaining configuration 
across several formats. So now the middleware authors job is easy, at 
the expense of the administrator who now has to maintain a set of 
configurations files like this

middle1.ini
middle2.xml
middle3.py
middle4.pth
middle5.yaml
middle6.etc
middle7.etc2

IMHO, we should state some simple requirements for how we would like 
configuration to be handled. Here is an idea of the type of thing I mean

1. In order to reduce the documentation workload on middleware and 
framework authors, it is desirable to have a single configuration 
language which is supported in all WSGI environments.

2. In order to simplify the task of WSGI server administrators, it is 
desirable that the configuration of an entire middleware stack be 
storable in a single file/hierarchy of nested/include files.

3. In order to maximise internationalization opportunities, the chosen 
configuration mechanism should support the widest possible range of 
character encodings, and it should be easy for the user to explicitly 
specify the encoding.

On the latter point, I believe we need to discourage ascii-centrism and 
encourage unicode-awareness. More international dialogue! ;-)

[Peter Hunt]
 > The other option I see would be inventing something similar to JNDI...

Well, I think that 99% of the time, configuration consists of just a 
list of name/value pairs, although the value can obviously have complex 
structure. Given that dynamically building data structures is where 
python really shines, it should be possible to come up with something 
flexible and powerful enough to cover the vast majority of situations.

I'm perhaps being a little strident now ;-), but I think we should 
address the character encodings issues head-on, and eliminate any 
possible configuration technology that doesn't support easy handling of 
character encodings.

Which leaves python (PEP 263) and XML (<?xml encoding=""?>) top of my list.

Kind regards,

aláin ó cinnéide