[Web-SIG] Standardized configuration

[Phillip J. Eby]

At 01:57 PM 7/11/2005 -0500, Ian Bicking wrote:
>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'm going to go ahead and throw my hat in the ring here, even though I've 
been trying to avoid it.

Most of the stuff you are calling middleware really isn't, or at any rate 
it has no reason to be middleware.

What I think you actually need is a way to create WSGI application objects 
with a "context" object.  The "context" object would have a method like 
"get_service(name)", and if it didn't find the service, it would ask its 
parent context, and so on, until there's no parent context to get it 
from.  The web server would provide a way to configure a root or default 
context.

This would allow you to do early binding of services without needing to do 
lookups on every web hit.  E.g.::

     class MyApplication:
         def __init__(self, context):
             self.authenticate = context.get_service('security.authentication')
         def __call__(self, environ, start_response):
             user = self.authenticate(environ)

So, you would simply register an application *factory* with the web server 
instead of an application instance, and it invokes it on the context object 
in order to get the right thing.

Really, the only stuff that actually needs to be middleware, is stuff that 
wraps an *oblivious* application; i.e., the application doesn't know it's 
there.  If it's a service the application uses, then it makes more sense to 
create a service management mechanism for configuration and deployment of 
WSGI applications.

However, I think that the again the key part of configuration that actually 
relates to WSGI here is *deployment* configuration, such as which service 
implementations to use for the various kinds of services.  Configuration 
*of* the services can and should be private to those services, since 
they'll have implementation-specific needs.  (This doesn't mean, however, 
that a "configuration service" couldn't be part of the family of WSGI 
service interfaces.)

I hope this isn't too vague; I've been wanting to say something about this 
since I saw your blog post about doing transaction services in WSGI, as 
that was when I first understood why you were making everything into 
middleware.  (i.e., to create a poor man's substitute for "placeful" 
services and utilities as found in PEAK and Zope 3.)

Anyway, I don't have a problem with trying to create a framework-neutral 
(in theory, anyway) component system, but I think it would be a good idea 
to take lessons from ones that have solved this problem well, and then 
create an extremely scaled-down version, rather than kludging application 
configuration into what's really per-request data.