[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.

[Alan Kennedy]
 >> 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.

[Alan Kennedy]
 >> 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.

http://java.sun.com/dtd/

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.



[Alan Kennedy]
 >> 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, 
and why.

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.

Examples include

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)
3. Wiki
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 
URL-space.

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 
framework-specific concern.

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 
frameworks.

3. That a combination of multiple connected middleware components *is* 
an application.

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

Regards,

Alan.