On Tue, 2006-03-28 at 14:56 -0800, Shane Stixrud wrote:
Writing configuration files and configuration file parsers is boring, frustrating, error-prone work. If elektra is the right solution we should see new projects embracing it. After that happens, you'll start seeing buyin from the established projects.
How to get more new projects to use it? More language bindings would definitely help....
That may be the case, but for some applications say named, dhcp or ldap does it not seem reasonable that a generic configuration format may require a balance between putting less logic in the config structure requiring more of the application? If so I can see how this would be a turn off for some applications even though it may be an overall win for the system as a whole.
dhcp snippet (dhcp is not on here so hopefully this snippet is valid): default-lease-time 21600; subnet 10.202.46.0 netmask 255.255.255.0 { use-host-decl-names on; option log-servers 10.202.46.2; host ws001 { hardware ethernet 00:11:22:33:44:55; fixed-address 192.168.0.1; default-lease-time 10000 filename "/lts/vmlinuz-2.4.26-ltsp-1"; } }
Here's the same thing in .ini style: [global] default-lease-time 21600
[10.202.46.0] netmask 255.255.255.0 use-host-decl-names on log-servers 10.202.46.2
[ws001] subnet 10.202.46.0 hardware-ethernet 00:11:22:33:44:55 fixed-address 192.168.0.1 default-lease-time 10000 filename "/lts/vmlinuz-2.4.26-ltsp-1"
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.
-Toshio