[Web-SIG] more comments on Paste Deploy

[L.C. Rees]

> Sure, as long as Paste Deploy's config syntax is optional for
> whatever-we're-building. :^)

Some of the pain and angst over choosing one solution to the WSGI
application composition problem could be treated by dividing the
composition process into (at least) three parts:

1. Configuration parsing

Configuration information is read from multiple files or one big file
all at once (something ConfigParser in the standard library, for
example, already has support for) or selectively.  The information,
stored in whatever format (INI, Python, even XML, pick your poison),
is parsed (with  optionally validation) into a uniform internal Python
format. The internal format would be a sequence of tuples. Each tuple
would contain three elements:

a. An identifier consisting of tuple that contains two elements, an
(optional) qualifying prefix and a more specific identifier.
b. Configuration parameters that have been parsed into a tuple of
positional arguments.
c. Configuration parameters that have been parsed into a dictionary of
keyword arguments.

2. Dispatching

A dispatcher would take the sequence of tuples from the parser and
resolve the identifier to an adapter. The dispatcher would then strip
out the identifier, and pass a tuple containing the tuple of
positional arguments the dictionary of keyword arguments to the
adapter.

Different identifier schemes could be accommodated by the same
dispatcher as needed.

3. Adapting

The adapter would be responsible for taking the configuration data in
the tuple passed to it by the dispatcher and returning a configured
WSGI application.

An approach that decomposes the WSGI application composition process
into distinct stages would accommodate different approaches to each
stage of the composition process while allowing interoperability
similar to how WSGI allows heterogeneous Python web applications to
live together in (greater) peace and harmony-lcr