[Web-SIG] cusom config files. was (PasteDeploy 0.1)

[Phillip J. Eby]

At 10:17 AM 8/24/2005 +1000, Rene Dudfield wrote:
>Hey,
>
>are custom config files with custom parsers needed or wanted for 
>configuration?
>
>Would not a .ini, python, xml, sql db, file system, or even apache
>style config file be better?
>
>If a common format is used then:
>1) less code to maintain.
>2) less to learn/document.

That would only be true if there were a common format that worked.  The 
main problem is that all of those formats simply push the complexity from 
the syntax to the semantic level!

One previous proposal was for an .ini variant that could handle pipelines 
easily, but could not do URL dispatch without awkward hacks to the .ini 
syntax.  .ini files are extremely difficult to use for any kind of nesting.

Python files are possible, and that approach has been discussed a bit, but 
the full Python language may be a little overpowered for configuration, 
while at the same time not offering convenient constructs for simple things.

XML is too verbose, redundant, and strict, and simply pushes the issue to 
defining the XML schema involved.  Also, the very use of XML tends to 
attract XML geeks who then nitpick about whether you're using XSD or DTDs 
properly and why you shouldn't use attributes for data, blah blah blah.  ;)

I'm not sure what you mean by SQL DB, but if you mean putting the 
configuration in a database, I don't see why that would be useful or 
good.  Similarly, I don't know what you mean by "file system".

Apache-style configuration (like ZConfig) can also get very ugly very 
quickly when nesting gets involved, and it has no built-in way to reference 
items within the configuration, so like XML and .ini files it forces you to 
invent your own reference semantics layered atop the basic syntax.

(You didn't mention YAML, but I'll point out anyway that it has way too 
many subsyntaxes, punctuation tricks and suchlike to be easy for humans to 
write, while not expanding on the capabilities of XML that much.)

Really the problem is that of the basic possible syntaxes, Python and XML 
are the only ones that come close to having adequate expressive power.  XML 
falls short of being able to implement the more complex use cases without 
creating some sort of mini-programming language within XML, and Python 
requires verbose procedural constructs to create declarative hierarchies 
that would be easy in XML.

Thus, the proposal that I've been fronting at the moment is actually a 
hybrid of XML-like structure and Python-like language characteristics.  If 
it fails, I'm not sure what I'd fall back to.

The nice thing about this "Python data language" is that I can see a lot of 
applications besides web stuff.  For example, Chandler's UI really wants to 
have a more declarative format than can easily be done in pure Python, but 
a more computationally-flexible format than can easily be done in XML.  I 
can basically see this "data language" being used for a lot of things that 
otherwise would be done crudely with .ini, .xml, ZConfig, or one of the 
other "standard" formats.  Consider, for example, the grotesque hack of 
.ini syntax used by the "logging" module to define loggers, handlers, and 
filters -- and then consider what it could look like if it used this "data 
language" instead.

I would say that there is definitely a real need for a declarative Python 
object definition syntax that supports nesting and internal references, and 
so if we can come up with something good, it can and should *become* a 
standard for such purposes, well beyond the scope of its initial mission of 
being a WSGI deployment syntax.