[Web-SIG] Re: WSGI and Configuration
Phillip J. Eby
pje at telecommunity.com
Sat Nov 13 18:57:46 CET 2004
At 04:05 PM 11/13/04 +0000, Alan Kennedy wrote:
> > 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.
>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
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
More information about the Web-SIG