On Thu, 2003-02-06 at 22:01, Lynn Avants wrote: > Eric and I are NOT proposing flattening the tree structure, but alloing for > a inbetween layer that is actually interpretable by a human. Many humans > have a need to fiddle w/o a API and want to find/fix possible bugs in a > running configuration. The flat mid-layer allows for this to happen and also > makes life simpler for packagers that may need the shared base information. > You wouldn't want to make any changes in the flat file, you would want to > take the literal path that the flat file contains to locate exactly _where_ a > variable could be modified. This also saves on the dynamic nature and > completeness of the documentation needed to grasp what is actually happening > with the db.
Documentation is important. It is important if we want things to be done right (not some nazi concept of "right," but right meaning "works all the time"). For a package maintainer to go into a shell fragment looking for a variable that has a current value that he thinks is associated with the operation he is executing is almost always the wrong move. Maybe it is the right variable; maybe not. Documentation tells. > Possibly I am now rambling on about something that many feel is superficial, > but with a strictly mandated API frontend, you might as well get rid of the > editor on the disk. I would look far enough to figure out that everything is > controlled by db-binary and look for something a little more adaptive to > brute force changes if necessary. Per se, when Xdistro's propietary installer > fsck's my setup for any reason (and I haven't met one that hasn't), I can > manually fix the error. The suggested db doesn't leave much room for that. > Someday XFree on Linux will figure out that a RIVA 128 won't work > on a framebuffer correctly. When I can't fix that by hand, I'll likely be > using FreeBSD on this desktop or something else a little more propietary. Actually, in this implementation, the config-db is quite easily manipulated by hand along the lines of qmail (my inspiration in form if not in license) # echo -n "172.24.8.24" > /leaf/cdb/interfs/eth0/ipaddr # /leaf/bin/leaf-trig ipchange eth0 Just as tweaker friendly. I wouldn't have it any other way. And frankly, using e3 in vi mode over even a 19200 serial console is not a dream. Especially on a 1000-line shell fragment. ;-) > M$ protects the user from controlling much of their system. This is among > one of many reasons many of us do not use their products. Please don't > protect me from my own system. I regress. ;-) I regret if I have done anything to imply that the config-db is off limits to users. I only meant to have it off limits to package maintainers, and even then only loosely off limits. During the backup and boot process packages are "allowed" (and even encouraged) to take control of their own config-db files. This fragmentation concept stems somewhat from my frustration in having to modify files in one package to affect the behavior of another. Of note is the addition of terminfo to etc.lrp to assist the installation of vim (to unhobble my serial boxes ;-)) Take a look at the code in cvs when you get a chance. I think that it will put your fears at bay. -- ----------------------------------------------------------------------- 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
