[Web-SIG] WSGI adoption

[Peter Hunt]

You have valid points on the python-based configuration files.

First, let me go over what a configuration file is. A configuration
file defines one instance of middleware.

Let me explain what "before" and "after" are. If I have a given
middleware "module.middleware2", and
before=module.middleware0,module.middleware1, and
after=module.middleware3, the gateway will essentially do a call like
this:

module.middleware3(module.middleware2(module.middleware1(module.middleware0(...))))

Configuration files won't actually specify module.middleware1, they
will specify a configuration file which will have the middleware
"name" as module.middleware1. That way, we can specify separate
parameters to middleware1.
On Thu, 25 Nov 2004 19:51:19 -0500, Phillip J. Eby
<pje at telecommunity.com> wrote:
> At 06:14 PM 11/25/04 -0500, Peter Hunt wrote:
> >Regarding configuration file format, I still think that we should use
> >Python source, as it is easy to parse and easy to specify advanced
> >configuration information. This has already been shown to work: just
> >look at distutils setup scripts.
> 
> Distutils setup scripts have a different audience: Python programmers.  The
> audience for editing a WSGI application deployment file would include
> end-users, some of whom might like to use some sort of GUI administration
> tool to do the editing.
> 
> 
> >End user editability: we're talking about x = y vs. x = "y" here.
> 
> Don't forget escaping of quotes, case-sensitivity, and booleans, just for
> starters.  These are all areas where ConfigParser beats Python hands-down
> for non-programmer users.
> 
> 
> >I
> >think that Python source code is just as readable as ConfigParser.
> >
> >Sectionability: section.option = "value"
> 
> And where is 'section' going to come from?
> 
> Mind you, I'm not married to ConfigParser, but so far it seems to be the
> best thing, short of defining some new format of our own.  (Which I don't
> think is such a hot idea.)
> 
> 
> >I think a more important issue is how they will be deployed. Each
> >configuration file should specify three things: "before", "after", and
> >"middleware". "middleware" is the 'name' of the middleware that this
> >file configures. "before" is a list of the _config files_ which
> >specify middleware that will be called before the one being defined.
> >"after" is the same, except of middleware which will be called after.
> 
> Sorry, I don't understand this.  Please define what you mean by "called
> before" and "called after".  I also don't get what the 'name' is for.  What
> do you do with it?
> 
>