[Web-SIG] Standardized configuration

[Chris McDonough]

I've also been putting a bit of thought into middleware configuration,
although maybe in a different direction.  I'm not too concerned yet
about being able to introspect the configuration of an individual
component.  Maybe that's because I haven't thought about the problem
enough to be concerned about it.  In the meantime, though, I *am*
concerned about being able to configure a middleware "pipeline" easily
and have it work.

I've been attempting to divine a declarative way to configure a pipeline
of WSGI middleware components.  This is simple enough through code,
except that at least in terms of how I'm attempting to factor my
middleware, some components in the pipeline may have dependencies on
other pipeline components.

For example, it would be useful in some circumstances to create separate
WSGI components for user identification and user authorization.  The
process of identification -- obtaining user credentials from a request
-- and user authorization  -- ensuring that the user is who he says he
is by comparing the credentials against a data source -- are really
pretty much distinct operations.  There might also be a "challenge"
component which forces a login dialog.

In practice, I don't know if this is a truly useful separation of
concerns that need to be implemented in terms of separate components in
the middleware pipeline (I see that paste.login conflates them), it's
just an example.  But at very least it would keep each component simpler
if the concerns were factored out into separate pieces.

But in the example I present, the "authentication" component depends
entirely on the result of the "identification" component.  It would be
simple enough to glom them together by using a distinct environment key
for the identification component results and have the authentication
component look for that key later in the middleware result chain, but
then it feels like you might as well have written the whole process
within one middleware component because the coupling is pretty strong.

I have a feeling that adapters fit in here somewhere, but I haven't
really puzzled that out yet.  I'm sure this has been discussed somewhere
in the lifetime of WSGI but I can't find much in this list's archives.

> Lately I've been thinking about the role of Paste and WSGI and
> whatnot. Much of what makes a Paste component Pastey is
> configuration;  otherwise the bits are just independent pieces of
> middleware, WSGI applications, etc.  So, potentially if we can agree
> on configuration, we can start using each other's middleware more
> usefully.
>
> I think we should avoid questions of configuration file syntax for
> now.  Lets instead simply consider configuration consumers.  A
> standard would consist of:
>
> * A WSGI environment key (e.g., 'webapp01.config')
> * A standard for what goes in that key (e.g., a dictionary object)
> * A reference implementation of the middleware
> * Maybe a non-WSGI-environment way to access the configuration (like 
> paste.CONFIG, which is a global object that dispatches to per-request 
> configuration objects) -- in practice this is really really useful, as 
> you don't have to pass the configuration object around.
>
> There's some other things we have to consider, as configuration syntaxes 
> do effect the configuration objects significantly.  So, the standard for 
> what goes in the key has to take into consideration some possible 
> configuration syntaxes.
>
> The obvious starting place is a dictionary-like object.  I would suggest 
> that the keys should be valid Python identifiers.  Not all syntaxes 
> require this, but some do.  This restriction simply means that 
> configuration consumers should try to consume Python identifiers.
>
> There's also a question about name conflicts (two consumers that are 
> looking for the same key), and whether nested configuration should be 
> preferred, and in what style.
>
> Note that the standard we decide on here doesn't have to be the only way 
> the object can be accessed.  For instance, you could make your 
> configuration available through 'myframework.config', and create a 
> compliant wrapper that lives in 'webapp01.config', perhaps even doing 
> different kinds of mapping to fix convention differences.
>
> There's also a question about what types of objects we can expect in the 
> configuration.  Some input styles (e.g., INI and command line) only 
> produce strings.  I think consumers should treat strings (or maybe a 
> special string subclass) specially, performing conversions as necessary 
> (e.g., 'yes'->True).
>
> Thoughts?