On Tue, 2003-02-04 at 14:19, Matt Schalit wrote: > > > Chad Carr wrote: > > > > May I suggest that the config-db be maintained as a "config-tree," with > > the root at /leaf-cdb (or something shallow like that) and keys may be > > nested as deeply as needed by creating directory levels. I.e. you could > > make the key > > > > interfaces/eth0/ipaddr > > > > like this: > > > > echo -n "172.24.8.24" > /leaf-cdb/interfaces/eth0/ipaddr > > > > I also like the idea of a config-tree, Chad. It's proven > itself useful for Linux a la /proc. > > > I wish the config-tree api to have significant lattitude in how > it displays the data: > > > a) Something along the lines of a -H argument the way "who -Hu" > prints out column headers. > b) The ability to dump var=value pairs to stdout.
That's cool. I am game for anything. It seems that the second way would be most useful for operation, but perhaps the first would be good for display purposes, or something. > Would you like to remark any furthur on how a tree is significantly > better than a single config-db file and how the tree would store a > variable's "type" information, for instance? The main reason we (at Toshiba) chose a tree is that it allows for the display of complex data structures without the use of any parser. It also allowed us to separate centralized configuration data into separate files that would not wreak havoc with RPM's (we used RedHat at Toshiba) hellish dependency structure and would not require the use of carefully hand-rolled postinstall scripts to modify global configuration files. Not as much of an issue here since packages are not dependent on LEAF, but what the hell. It also allows a package to "own" (and back up) a piece of the central config-db without fear of it getting overwritten by another package, horked up by another package, deleted by another package, etc. The main part of the system is the templating and trigger system that abstracts the config-db away from the runtime requirements of the packages themselves. It allows any sort of transformation to take place between the config-db and the actual configuration of the running application. As far as type info, there should be none. The storage should be strings (everything in the file is considered part of the "value"; we may have to consider a proper shell escaping feature in the api) and the caller should determine how he is going to interpret the data. What is an example of needed a real "type" and what would they be? The hierarchy could handle just about anything, in my opinion, but I don't think type information is really needed. I could be wrong. ----------------------------------------------------------------------- Chad Carr [EMAIL PROTECTED] ----------------------------------------------------------------------- ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
