On Fri, 2006-03-31 at 13:33 -0300, Avi Alkalay wrote: > On 3/28/06, Toshio Kuratomi <toshio@xxxxxxxxxxxxxxx> wrote: > > I'd argue that as the number of subnets and special case workstations > > goes up, the ability of a system administrator to read and understand > > the flat file is going to be markedly harder than for the admin to read > > the custom-crafted dhcp-config syntax. > > > > So if the end-goal is to keep the system-administrator's poor brain from > > exploding while manually editing the files, I'd say custom-crafted > > config files can be a win versus the generic one-size-fits-all approach. > > > > Thats not the end-goal. > You came into the thread late. It's not Elektra's end-goal, it is the end goal of some of the posters to whom I was replying. > See, the end goal is to standarize configurations in such a way that > one program with proper permissions can directly interact with another > program's configurations. So in your DHCP server problem, an LDAP > helper can easily change DHCP's configuration to add/remove/change > some host's fixed IP address, for example, without having to ask the > sysadmin (a human being) to edit it manualy, and without having to > regenerate the entire config file again. > So Elektra's end goal is a common on-disk format? And libelektra is a "reference implementation" providing an API that the developers think is sane? Which clears up the following areas: * GConf as a backend was not a real long term direction for the software. * Making Elektra a backend to GConf/KConfig/etc is providing an additional API rather than the canonical one. It doesn't compromise the core goal of a common on-disk format. Please further clarify if necessary. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
