On Thu, 30 Mar 2006, sean wrote:
For ad-hoc interactive usage that looks worse than what we have today;
call up a config file and page through it to see the information you want.
It is but one possible example. My point is how the keys and values are
formated is flexible, the hierarchical key/value pair storage medium contains
all of information required to recreate the dhcpd.conf file in its
entirety. The key descriptions and user comments can be stored as "files"
associated with these same directories/keys and then compiled+arranged on
demand for user consumption.
Perhaps this example is more to your liking?:
cfg_mgr --interactive
display -embed -nodesc -comments /dhcp/sw/dhcpd/subnets/10.202.46.0-24/*
10.202.46.0-24 {
# User comments go here
use-host-decl-names = on
}
options {
# User comments go here
log-servers = 10.202.46.2, 10.202.46.3
}
hosts {
ws001 {
# User comments go here
fixed-address = 192.168.0.1
# User comments go here
default-lease-time = 10000
# User comments go here
filename = /lts/vmlinuz-2.4.26-ltsp-1
# User comments go here
hw = ethernet:00:11:22:33:44:55
}
}
}
But the difficult issue isn't really what tools might be possible after
a unified config system is in place. Rather, it's how to get enough
apps to use the config system in the first place. My own view is that
concentrating on the needs of _developers_ not users and sysadmins
is the way to success. The user and admin tools are the easy part.
I agree the tools shouldn't be the focus, my point though is the with the
right storage design / medium existing tools would be usable.
Cheers,
Shane
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
