On 3/29/06, Bill Crawford <billcrawford1970@gmail.com> wrote:
How does .ini format give you containers beyond the first level? By numbering
the keys? ugh.

The ini format was a bad example because you get 2 dimensions only.
On Elektra you'll have something like this:

> > default-lease-time           21600;
> > subnet netmask {
> >    use-host-decl-names      on;
> >    option log-servers ;
> >    host ws001 {
> >        hardware ethernet    00:11:22:33:44:55;
> >        fixed-address;
> >        default-lease-time   10000
> >        filename             "/lts/vmlinuz-2.4.26-ltsp-1";
> >    }
> > }

system/sw/dhcpd/default-lease-time = 21600
system/sw/dhcpd/subnets/ = on
system/sw/dhcpd/subnets/ =
system/sw/dhcpd/subnets/ =
system/sw/dhcpd/subnets/ = 10000
system/sw/dhcpd/subnets/ = /lts/vmlinuz-2.4.26-ltsp-1
system/sw/dhcpd/subnets/ = ethernet:00:11:22:33:44:55

The dhcp config file format is a much better match for a) the way people
think if they know the problem domain b) allows *hierarchy*. XML at least
gets that right (and I *don't* think xml is the answer).

Anyway, Elektra also provides standard ways for you to represent this hierarchy in an XML format, useful for exporting and importing.

> But things change considerably
> when instead we deal with all configuration elements as keys and their
> values in a filesystem like structure.

And this is the issue. Look at the mess that is SNMP MIBs. Can you read
those? Can you?

Again, the point is not you (a human being) to read them, but make them accessible in an atomic way to any other (non-human) program.