10:33 a.m.
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.
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.
Another more easy to understand problem that a global standarized
configuration standard solves is the ability for you to buy a
commodity video card, install it on your system, and the vendor
scripts will safely, automatically, and precisely change your X.org
standarized configuration to inject itself there. Currently they have
to ask you to use vi plus your human brain and human eyes to make the
xorg.conf changes by yourself, because it is too hard for them write
an xorg.conf "compiler". Actualy, we know that what really happens is
a simple "Linux is not suported" statement from these vendors.
Avi
11:20 a.m.
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
12:23 p.m.
On 3/31/06, Toshio Kuratomi <toshio(a)tiki-lounge.com> wrote:
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:
It can be on-disk, or remote. It depends on the backend you'll use.
Currently we only have local on-disk backends as filesys and the
superfast Berkeley DB.
The initiative has 3 focus areas:
1. Definition of a standard key/value pair hierarchy, namespace and
semantics. Se some written standards-by-example here:
http://www.germane-software.com/repositories/elektra/trunk/doc/specs/
2. API implementation to access the key/value pairs namespace
3. Produce quality patches for popular softwares as X.org, Samba,
KDE's KConfig XT and Gnome's GConf
While thightly integrated to focus 1, focus 2 can be redone without
compromising the work made on focus 1 because this last is 100%
conceptual.
* GConf as a backend was not a real long term direction for the
software.
Yes. Was just a test. GConf is higher level compared to Elektra, so
doesn't make sense to put Elektra on top of GConf. What we'll have in
near future is GConf and KConfig XT on top of Elektra, so all G- and
K-apps will be automatically elektrified, without changing a comma in
their source. And more: G-apps will be able to access K-apps configs
and vice-versa. Even more: we finaly will be able to have one single
place for general things like proxy configuration, desktop background,
etc (althought Elektra is more than just desktop configuration).
* 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.
I'm not sure if I understand this due to my english limitations. But I
think an answer is in my previous paragraph.
There is a very graphical and easy to understand OOo presentation
about Elektra, updated this morning, at
http://www.germane-software.com/repositories/elektra/trunk/doc/elektra.odp
I delivered an old version of it on KDE's Akademy event few years ago
in Germany. And will be probably delivered again this year in Desktop
Symposium in Ottawa.
Regards,
Avi
6598
days inactive
6598
days old
2 comments
2 participants
participants (2)
-
Avi Alkalay -
Toshio Kuratomi