<[EMAIL PROTECTED]> said:
[...] > > libconf doesn't store the config information elsewhere than where they > > are - in the config files. Libconf > > In the end, there must only be one copy of the configuration information > (any other system with meta-configuration eventually has problems with > diverging configurations). So, if you want the configuration stored in XML > or LDAP, it means the application needs to be using that directly. sure, but libconf can be used to synchronise ldap and the config files. If everything were in ldap, libconf would be useless, and configuring a linux system would be super easy :) actually we should code every new config tools in such way that it read/write config infos from/to ldap, and libconf would synchronize between ldap and the config files for the software that are not LDAP aware (ie 80% of the softwares). > > For applications where configuration can be stored in LDAP (such as > Postfix canonical maps etc), the backend should be capable of supporting > this, but at present most systems capable of reading configuration from > LDAP still require a config file to tell them where to find the LDAP > server (among other things). This will change I think, as the use of DNS > to locate services becomes more popular (ie Kerberos-style SRV records). if the backend is capable of that, no need to use libconf, because no synchronization is needed. > > > provides a mapping of these > > information into a convenient perl structure. It is planed to have an > > xml output, and a ldap output. You would then be able to ask libconf to > > write an xml file from a standard config file. Or to feed a ldap base. > > I think the big thing is that the API for frontends needs to be defined, > as perl structeres aren't that portable (for instance, consider a remote > Windows front-end ...). sorry, I don't understand your point completely :/ -- dams
