On 3/28/06, Toshio Kuratomi toshio@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
On Fri, 2006-03-31 at 13:33 -0300, Avi Alkalay wrote:
On 3/28/06, Toshio Kuratomi toshio@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
On 3/31/06, Toshio Kuratomi toshio@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
devel@lists.stg.fedoraproject.org
-
Avi Alkalay -
Toshio Kuratomi