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. _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
