[Web-SIG] Re: WSGI and Configuration
py-web-sig at xhaus.com
Sun Nov 14 17:21:16 CET 2004
>>> 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.
[Phillip J. Eby]
> 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)
[Phillip J. Eby]
> 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"?
Well, java authors don't have to document every web servers config
because J2EE has XML standards for all aspects of deployment configuration.
Note that this standardization facilitates the development of end-user
tools (e.g. with easy-to-use GUIs, or autogeneration with XSLT
stylesheets, etc) for simplified J2EE deployment.
>> 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! ;-)
I forgot to add what I consider to be another important requirement:
4. Ideally, it should be possible to generate deployment configuration
files automatically, e.g. from GUI programs, specialized web-apps, etc.
This is to support development of tools which simplify deployment
configuration, thus facilitating ease-of-deployment for non-technical users.
I think that in order to progress this discussion, we need to have a
clearer definition of middleware, how middleware components are used,
My understanding of middleware is as follows.
Among other things, middleware components should enable implementation
of functionality that is common to all web applications. This is to
facilitate standardization and reuse of such components across WSGI
environments, and to enable WSGI users to select "best-of-breed"
components for particular functions.
1. Authentication. Authentication is a very common function for web
applications, and implementations of authentication functionality can
range from simple (e.g. textual list of name/password/role triples) to
complex (e.g. auth data stored in an LDAP server).
2. Session-handling. Session-handling is a complex area, requiring
handling of cookies, url-rewriting, persistence (RDBMS, flat-file, etc),
security (e.g. secure IDs, etc) and potentially syndication of sessions
across a federation of cooperating servers. This is one area where
almost every single python web application/framework has re-invented the
wheel, but in a different shape every time, thus preventing reuse.
In an ideal world, I would like it to be possible to use WSGI middleware
to create or extend compound applications. A good example of this is
TRAC (http://www.edgewall.com/trac/), which integrates the following
facilities in a single integrated whole
1. Source code repository browser
2. Ticket tracking system (i.e. bugs, etc)
4. Timeline management
But TRAC is essentially a set of separate components, each implemented
as a separate CGI script, which provide views of and access to the
contents of several underlying databases.
If it were possible to separate out the TRAC authentication and
session-handling into WSGI middleware components, then it could be
possible to seamlessly extend TRAC to support other features, e.g.
Blogs, CVS-repository browsing (TRAC is currently svn only), etc. For
example, if the auth were separated out, then I could use the same auth
middleware/database to support a blogging system, which could be
"integrated" into TRAC by mapping a new URL hierarchy into the TRAC
Picture a situation where a deployer is trying to build a middleware
stack that implements an "application", which is really the invocatrion
of a series of middleware components. If the deployer has to work in
different configuration file formats for each middleware component, then
they will have to learn several different configuration syntaxes. Also,
they would mostly have to edit the configuration files manually: It
would also be much more difficult to write standardized configuration
management tools which would allow configuration of the
stack/application through a GUI or a web front-end.
Sure, there is an argument to be made that these are all framework
concerns, i.e. that gluing application components together is a
But the argument could also be made that these are server concerns, and
that standardised middleware configuration could be used to facilitate
gluing together disparate middleware components and applications to make
a seamless whole, without the involvement of a framework.
So I suppose what I am really saying is
1. I think there is an opportunity here, by standardizing middleware
configuration, to forge a standard for total portability of middleware
between WSGI environments.
2. That such a standard would also be used as standard configuration for
3. That a combination of multiple connected middleware components *is*
4. That a standardized method of configuring, connecting and invoking
middleware components *is* a framework.
One issue I think hasn't been addressed is how to instruct a middleware
component what is the next application/middleware to be invoked in the
stack. If I build a middleware stack, with say auth and session
components at the bottom, and a variety of applications on top (which
vary by URL), how do I instruct the auth component to invoke the session
component next? Through an entry in the WSGI environ dict?
Somehow, I get the feeling that my picture of middleware components
doesn't gel with other people's views :-)
More information about the Web-SIG