[Web-SIG] Re: WSGI and Configuration

[Ian Bicking]

Alan Kennedy wrote:
> 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.

Well, this doesn't preclude dynamic either.  Unless the server requires 
that PATH_INFO be empty, the application always has the option to 
delegate further.  All WSGI applications should look the same to the 
server/gateway, regardless of if they are middleware of terminal 
applications.

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

You mean standardizing middleware, or extending WSGI?  I'm comfortable 
with what WSGI allows, I don't think it needs to be extended at all.  As 
for standardizing middleware, I think that's a separate standard by a 
separate name, and we'll need some implementation experience under our 
belts.

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

Well, here's the middleware I'm using:

* cgitb_catcher, catches unhandled exceptions and formats a response 
using cgitb.
* dispatch, a crappy URL parser; only interesting in that it also can 
add middleware via the URL (useful for testing)
* gzipper, a gzip-encoding middleware
* httpexceptions, which catches specific exceptions (e.g., 
HTTPTemporaryRedirect) and turns them into proper responses.  Probably 
the least WSGI-ish of these middlewares.
* lint, a standard-verifying middleware that doesn't otherwise effect 
valid requests or responses
* recursive, a middleware that allows for recursive calls into the 
application.  It's limited to calls below its position in the middleware 
stack.  This was necessary for implementing some Webware APIs.  And it 
seems pretty useful too.  It allows for forwarding (passing control) and 
inclusion (doing a recursive call).
* session, a session handler
* urlparser, a URL parsing middleware.  It parses the first part of 
PATH_INFO, and finds the next resource.  If the next resource is a 
directory, it creates a new URLParser and passes control to it; it also 
has hooks for adding other file->application converters.
* webkit.wsgiwebkit.webkit, which just takes a whole bunch of these and 
puts them together.

The only thing that has been very confusing for me is handling 
exceptions, and most of these don't do so very well.

I think sessions would be easy to standardize, because they are pretty 
boring.  You store stuff, later on you get it back.  There's lots of 
possible features (e.g., storing in a database), but the API is pretty 
stable and understood irregardless of those features.  Authentication is 
a little harder, but I think it's not too bad if you don't take on too 
much at once.  I think it's only so complicated because authorization 
often gets folded into authentication.  Authentication sources (e.g., 
LDAP) should be kept out of the middleware; instead a simple and neutral 
API for authentication sources should be used.

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