[Web-SIG] Re: WSGI and Configuration
py-web-sig at xhaus.com
Mon Nov 15 01:13:49 CET 2004
>> 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
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?
More information about the Web-SIG