[Web-SIG] Standardized configuration

[Ian Bicking]

Phillip J. Eby wrote:
> 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.

Well, it is if you implement it that way ;)  I think I'd prefer the term 
"filter" actually; less bad connotations for people.  But that's really 
unrelated to your point.

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

I guess I'm treating the request environment as that context.  I don't 
really see the problem with that...?

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

I don't see the distinction between a factory and an instance.  Or at 
least, it's easy to translate from one to the other.

In many cases, the middleware is modifying or watching the application's 
output.  For instance, catching a 401 and turning that into the 
appropriate login -- which might mean producing a 401, a redirect, a 
login page via internal redirect, or whatever.

I guess you could make one Uber Middleware that could handle the 
services' needs to rewrite output, watch for errors and finalize 
resources, etc.  This isn't unreasonable, and I've kind of expected one 
to evolve at some point.  But you'll have to say more to get me to see 
how "services" is a better way to manage this.

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

Applications always care about the things around them, so any convention 
that middleware and applications be unaware of each other would rule out 
most middleware.

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

What do they provide that middleware does not?

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

Per-request or not, from the application's side I don't see the 
difference.  It is convenient to put configuration into the request, 
though paste.CONFIG is also provided as a global variable that 
represents the current request's configuration.

In practice the configuration is usually identical for all requests, but 
I haven't seen any reason to enforce this.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org