[Web-SIG] Re: WSGI and Configuration

[Alan Kennedy]

[Alan Kennedy]
 >> 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?

[Ian Bicking]
 > 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.

So ISTM that discussing configuration of middleware stacks is partly a 
discussion about an URI->object resolution mechanism, i.e. mapping an 
URI hierarchy to a tree of python objects. The shape of the python 
object tree may be either

1. Static, i.e. built at container start-time, and where the container 
selects target application objects based on URI components in each request.

2. Dynamic, where the application objects themselves get to decide where 
the request is routed next, quixote-style. But it is still the 
container's job to actually resolve/import the next object down in the tree.

So I think we're definitely in framework-land.

I'm beginning to think that maybe the concept of framework-agnosticism 
doesn't fit with the concept of middleware stacks. A mechanism for 
constructing middleware stacks is a framework, an instance of a 
middleware stack is an application/hierarchy-of-nested-applications.

Maybe it's time to start thinking about WSGI Layer 2:- The middleware layer?

Or maybe we need to find other middleware examples besides 
authentication and session handling, which are the two things most often 
"pre-decided" with many servers and almost any web programming framework 
in any language (because they're such a pain). Maybe they are special 
cases that need to be considered separately anyway?

Regards,

Alan.