[Web-SIG] WSGI adoption

[Peter Hunt]

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.

End user editability: we're talking about x = y vs. x = "y" here. I
think that Python source code is just as readable as ConfigParser.

Sectionability: section.option = "value"

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.

Just my few ideas.


On Thu, 25 Nov 2004 17:34:49 -0500, Phillip J. Eby
<pje at telecommunity.com> wrote:
> At 04:57 PM 11/25/04 -0500, Peter Hunt wrote:
> >Fair enough; we can drop Zope from the priority list.
> >
> >I'd suggest simply using plain Python as a configuration file format.
> >It's just as easy to understand and far more flexible than
> >ConfigParser.
> 
> Flexibility of specifying the content isn't really a plus here.  End user
> editability, and *sectionability* are more important.  That is, it should
> be easy to have sections for the app, the web server, and general WSGI
> information.  For that matter, it should be possible for me to include
> settings for both mod_python and Twisted in the same configuration file,
> such that each one sees only the parts it cares about.  That way, an
> application developer can minimize the tuning knowledge needed by an
> application deployer, for platforms the developer cares about.
> 
> IMO, most of the content of the deployment configuration is either going to
> be constants or filenames.  For filenames, ConfigParser lets you
> interpolate variables, so if you want brevity of expression you can still
> do that without going to the full generality of Python.
> 
> 
> >Also, in terms of configuration files, I think an instance of each
> >middleware/application/gateway should get its own configuration file.
> 
> Yes, this is a per-instance deployment file I'm talking about.
> 
> 
> >While designing this configuration system, we should keep the idea of
> >shared hosting in mind, and that the host may want to run certain
> >pieces of middleware for everyone.
> 
> I was thinking that part of the configuration passed to an application's
> setup would be an optional "next application" value.  There are several
> ways that could be configured from the deployment file, such as simply
> specifying the filename of the deployment file for the next application, or
> by embedding a list of deployment files for middleware to be put "above"
> the current application.
> 
> I don't have a firm proposal either way for the specific mechanism yet.
> 
>