On Fri, 2006-03-31 at 13:33 -0300, Avi Alkalay wrote:
On 3/28/06, Toshio Kuratomi <toshio(a)tiki-lounge.com> 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