[Web-SIG] Re: WSGI and Configuration

[Phillip J. Eby]

At 04:05 PM 11/13/04 +0000, Alan Kennedy wrote:
>[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.

This babel you speak of, already exists.  It's not WSGI's job to force 
applications -- or servers -- into a single configuration format.

OTOH, I do believe that *deployment* configuration (i.e. telling apps or 
middleware where to *find* their configuration) is an appropriate 
responsibility of a WSGI server, and that having a standard way to get that 
information from the server to the app is an appropriate goal for the spec.


>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)

I think you're making this more complicated than it is.  Do Java 
application authors have to document every web server's configuration, or 
do they say, "here's the servlets, these are their options, see your 
server's doc for how to deploy them"?

ISTM that it's sufficient to say, "I'm a WSGI application, this is the 
module or file with my application object, and I need a path to my 
configuration file in the variable FOOBAR_CONFIG.  See your server's 
documentation for how to deploy me."


>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! ;-)

This goes a bit farther than I think is practical.  Servers, gateways and 
applications already exist, and they are not reasonably going to change 
their configuration formats.  The *only* place where trying to standardize 
configuration would even be *possible* is middleware, because before PEP 
333, no WSGI middleware existed by definition.

However, I personally don't see how any such standardization is 
*practical*, unless the mechanism itself is Python-based.  For example, 
writing a Python script to stack a bunch of middleware, configuring it in 
the process.

But even for that, I think we need to see more specific use cases for what 
these middleware stacks are going to *do*, because right now we (or at 
least I) don't even know enough about their requirements to be able to do 
meaningful design.