Re: use and abuse of debconf
> I think cfengine does something like that, in a less-information-tree-ish
> manner.
> I'm currently working on something that allows creation of different
> configuration files from a single source (i.e. ldap tree,database,
> whatever), and believe me - there are a _lot_ of different config file
> syntaxes. It would be cool - but A Lot Of Work, afaik.
> Apart from that, i wouldn't like limiting myself to XML configfiles, rather
> 'a source of configuration stuff' - i'll decide if i want that to be a
> database, ldap, XML, some other storage thing, or the files themselves,
> later.
I wouldn't force anyone to use XML. I propose XML as a way translate
information so the tools can deal with it. The users wouldn't see the xml
versions.
> > * A standard way to refer to a configuration option (xpath):
> > /interfaces/iface[1] would access the first iface, and
> > /interfaces/iface[2] the second.
> The only _real_ standard way would still be the config file itself, afaik ;)
> A base to generate config files from would be handy, but it has to be
> _totally_ in sync, always. And there's people who want to modify the
> original file itself, too.
> (i'd like to have my named stuff in a database, parts of my apache config
> maybe, but i like to keep touch with the 'oldstyle' configuration of lots of
> other stuff)
>
> > * The config file writer (and other tools) could easily created with
> > XSLT.
> Doesn't this confine us to XML ?
No, the idea is this:
The first thing one imagine is a set of programs, per each, config file
format to set and get values. A getter and a setter. But this approach can't
be useful with more complex configuration files, e.g. one with nested
structures, ordered rules, etc. So, instead of having getters and setters,
an intermediate XML formato could be created, via "xmlencoders" and
"xmldecoders", thus providing a data model suitable for handling any type of
configuration information.
Reply to: