On Thursday 06 February 2003 10:42 am, Charles Steinkuehler wrote: > Lynn Avants wrote: > > Let's say something like this: > > > > /db-tree/interfaces/eth1/ip_address (contains 192.168.1.254) > > > > /etc/db.cfg contains: > > PREFIX=/db-tree > > LAN_IP='cat /$PREFIX/interfaces/eth1/ip_address' > > > > Then the application uses: > > source /etc/db.cfg > > #Internal interface ip address to use > > $LAN_IP > > I'd like to see what Chad implemented, but off-hand, I think the above > would only be appropriate in an individual package's configuation script.
I plan to go through that tomorrow morning (hopefully). I'm looking forward to it as well. ;-) > You're flattening the tree structure of the database (which IMHO exists > to contain important information). Whose to say you didn't really want: > LAN_IP=`cat /$PREFIX/interfaces/eth2/ip_address` > > I always figured the DB would contain some form of structure, and would > be accessed indirectly (ie via an API), something more like: > > LAN_IP=`getdbvalue interfaces.eth2.ip_address` > > Note that slashes, whitespace, colons, or pretty much whatever we decide > could seperate the "branches" of the db for quering. It probably also > wouldn't be terribly hard to setup some state information (maybe with > exported shell variables) so you could do something like: > > dbuse interfaces.eth2 > LAN_IP=`dbgetvalue ip_address` > LAN_MASK=`dbgetvalue netmask` > > Of course, this is all pretty speculative at this point. I personally > figured the package configuration scritps would be doing very little > actual talking to the db (mainly registering itself, and any templates > and package-specific db config variables used), and that the really > messy stuff would happen with the template files and a central > application that parsed them, filled in the dynamic information, and > wrote out the result (similar to how server-side-includes work for > webservers). I really don't think we're as far off in opinion as what it might appear. I also think I may have over simplified my snippet. From examining what Eric has posted, Eric and I are definately following the same path of thought. 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. 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. 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. ;-) Thoughts? -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net ------------------------------------------------------- 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
