[Web-SIG] WSGI deployment config

[Ian Bicking]

Phillip J. Eby wrote:
> I imAt 12:47 PM 8/8/2005 -0500, Ian Bicking wrote:
> 
>> OK, this is starting to become a bit more clear to me...
> 
> 
> Cool.  :)  Sometimes the best way to get rid of confusing communication 
> is to make the communication even more difficult.  :)  (e.g., banning 
> the word "configuration")

Well, it wasn't really that per se; after reading through the latest 
thread between you and James it became a bit clearer what you meant by 
services.  You've been a bit vague about services up until now (and I'm 
not familiar with Zope or PEAK services, so I've just been guessing at 
what you've meant).

>> So for many services some middleware would still be necessary, if the 
>> service was able to do anything to the request.
> 
> 
> Well yeah, if you want to wrap an app rather than just use the service.

I'm thinking of any service that needs to modify the request and 
response, or watch the request in some way (e.g., a transaction service 
that needs to watch for unexpected exceptions, or a session service that 
needs to add a cookie to the response when starting a new session). 
Services certainly have a much larger scope than that, but then most of 
that larger scope is workable as mere "libraries" (except for the 
configuration problem, which services do address).

>> If you *don't* want a middleware for every request/response-modifying 
>> service, then you'd need some uber-middleware like I mentioned back in 
>> http://mail.python.org/pipermail/web-sig/2005-July/001532.html -- in 
>> addition to saving some frames in the call stack, that would probably 
>> make pipeline specification easier.  But maybe not a whole lot easier, 
>> as there's usually additional details (like ordering) that are 
>> necessary to specify in the context of a web request.
> 
> 
> Well, to me, the "uber middleware" is just an object with a generic 
> function for its __call__ method, that has "before", "after", and 
> "around" methods registered to do stuff like transaction wrapping, error 
> handling, and any other sort of middleware-ish things.  So, it's not 
> very "uber" in implementation complexity from my POV to have such a 
> thing, and it takes care of many of the stacking issues.

Uber in that it doesn't have any specific purpose, and really leads into 
the direction of framework instead of library.  All the middleware to 
date are targetted at providing one bit of functionality; there's a 
certain clarity to that.  A single more powerful middleware is 
interesting; but it's also harder to imagine it being complete.

>> The spec I gave in "WSGI deployment: an experiment" 
>> (http://mail.python.org/pipermail/web-sig/2005-July/001598.html) 
>> handles arbitrary kinds of branching, basically by naming both 
>> applications and middleware filters, and allowing application 
>> factories to call back into the configuration file.  So pipeline is 
>> just another application factory, just like urlmap or other kinds of 
>> branching.
>>
>> Maybe this could be handled with an application-building service since 
>> we're passing services around anyway.
> 
> 
> Hm.  An interesting point.  I haven't yet seen a branching/alternatives 
> syntax I like though.  The big problem IMO is that a branching mechanism 
> requires nesting ability, whereas pipelines are "flat and happy".  :)

I find the use of named applications/filters to make the nesting 
reasonable.  I'm happy enough with the syntax I propose.  But then, I 
also thing that there's still something to the idea of another layer of 
indirection, and configuration files that self-identify.

I really see no reason to think we can fully identify the Right Way to 
configure applications (including all meanings of "configure") here and 
now.  I'm happy with One Good Way, and future extensibility.  So I still 
think "# -*- config.loader:ref -*-" is a good idea.

> Unfortunately, .ini syntax rapidly breaks down when nesting begins, 
> which makes me tend to think that we should have a separate "site map" 
> file that maps locations and other rules to groups of pipelines.

Nesting is one way of looking at it; but then mere references work okay 
as well.  I think at any point we want to be able to say "get the thing 
from this file" instead of "get the thing from this section".  Given 
that it doesn't seem like nesting is a good fit.  Are there any specific 
problems you have with my previous proposal?

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