[Web-SIG] Standardized configuration
Phillip J. Eby
pje at telecommunity.com
Sun Jul 17 06:33:57 CEST 2005
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
This would allow you to do early binding of services without needing to do
lookups on every web hit. E.g.::
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
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
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.
More information about the Web-SIG