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. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com