[Web-SIG] Re: WSGI and Configuration

[Ian Bicking]

Alan Kennedy wrote:
> My understanding of middleware is as follows.
> 
> Among other things, middleware components should enable implementation 
> of functionality that is common to all web applications. This is to 
> facilitate standardization and reuse of such components across WSGI 
> environments, and to enable WSGI users to select "best-of-breed" 
> components for particular functions.

This is definitely what I'm getting at as well.  To do this we'd have to 
agree on WSGI keys and semantics for those keys.  E.g., session 
middleware might have a key "session.api", which was an object that had 
methods for things like .sid, .expire(), .clear(), etc.  Or maybe that 
would be presented in several keys; I think if the API has multiple 
levels of compliance, multiple keys would be a good way to indicate that.

Anyway, that process of standardization has to happen for each piece of 
middleware independently.

The other part which relates to configuration is how to keep this under 
control for the person who is deploying an application using this 
middleware.  Right now the functionality of these pieces of middleware 
are provided as part of larger frameworks.  It means you can't pick and 
choose, but in reality no one wants to pick and choose -- they'd much 
rather be presented with a single good choice.  As implementors this 
choice seems good, but we need to insulate users from it.

One way is to package a bunch of the middleware into one hunk.  This is 
pretty easy:

def framework(application):
     return middleware1(
         middleware2(middleware3(middleware4(application))))

Of course, that only works if the middleware is self-configuring, which 
is why I'm thinking about that.  But Phillip is thinking about how we 
configure this stack.

I guess if we start with configuring the stack it'll be clearer how to 
reference the pieces, and what information they'll have available to 
them.  Well, I think the referencing is more interesting than the 
information available, because I'd rather leave the configuration until 
runtime.

And maybe referencing isn't hard.  Each piece implicitly has a unique 
name associated with it that it uses for its keys in the environ dict. 
Well, there's nothing ensuring it's unique.  And there's no way to deal 
with conflicts now.  Or middleware that shows up multiple times (which 
is plausible).  Well, maybe it's not easy, but it's the same problem we 
already have.

[lots of stuff I agree with snipped...]
> One issue I think hasn't been addressed is how to instruct a middleware 
> component what is the next application/middleware to be invoked in the 
> stack. If I build a middleware stack, with say auth and session 
> components at the bottom, and a variety of applications on top (which 
> vary by URL), how do I instruct the auth component to invoke the session 
> component next? Through an entry in the WSGI environ dict?

I think the composition generally happens when the application is 
started up, as opposed to when a request is processed.

Well, that's only partly true.  URL resolution is a common case where 
the next piece of the stack is found dynamically.  And any dynamic 
application is another opportunity for dynamic middleware.  For 
instance, if my application needs session handling and no session 
handler has been put into the stack yet, maybe I'll put one in on my own.

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