[Web-SIG] WSGI adoption

[Phillip J. Eby]

At 11:22 PM 11/25/04 +0000, Alan Kennedy wrote:
>[Peter Hunt]
> >> 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.
>
>[Phillip J. Eby]
> > 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.
>
>Since I don't have a specific proposal myself, I don't want to criticise 
>approaches.
>
>But on reading the docs for ConfigParser, I think that it doesn't have 
>encoding support(?). Meaning that configuring internationalised strings 
>will be complex, which will definitely be problematic in a world where 
>most filesystems acccept unicode file names, for example.

Hm.  Interesting point.  I hadn't thought about unicode filenames.  I think 
I'd need a better understanding, though, of how Python deals with string 
filenames on a platform that uses unicode filenames, before I could suggest 
a solution.  It seems to me that such a solution could potentially be very 
simple.  Indeed, as long as the chosen encoding doesn't interfere with the 
parsing of the configuration file itself, one could simply use a 
configuration setting to define the encoding of the values.


>And lastly, it's got to be said: although we may dislike the awkwardness 
>and rigidity of XML, it is almost universally understood, at all levels of 
>technical ability.

I think you *greatly* overestimate its ease of use for a naive user.  It's 
trivially easy to change a single character in XML and break the whole 
thing, especially if you need to include a <, >, or &.  People with HTML 
experience don't understand why stuff breaks when you mix upper and lower 
case.  IMO, XML is simply not suitable for non-technical users, period.