On Sunday 02 February 2003 01:48 pm, you wrote: > Greg Morgan wrote: > > One of the things I had not designed but thought about was variables. So > > here's a possible definition in XML. > > XML. That's where I remember this whole idea coming to > a halt a year or so ago, when somebody suggesting using > this and I and a couple of other people said, "yikes." > > But still, regardless of that off the cuff response, I really > like your idea of a central database containing > varname = value > pairs that can be sourced. That's what I thought would > be a simple way to create a config-db that's readily available > to hand-editing, shell scripting, and higher level languages. > > Please can we keep the db simple? I think Charles concurs > with this in his post. At least he argues for straight text.
This is close to what I am thinking. I tried compiling "nocgi", but I am lacking a dependancy. I don't really think we would need it as opposed to shell utils that are available. A 'sed' substitution to change a global variable file (db) would work as well. ( sed 's/IP_ETH0=*/IP_ETH0=xx.xx.xx.xx/p ???) My line of thought to modifying the existing packages would be to add two text files: 1) A file that includes all variable names used with the package _except_ base variables that should already exist (ip addresses and the like) 2) A file that listed depedancies for the package (libm, libz, ifconfig, etc...). In the conf files themselves all variables should be inserted where necessary and the global db file should be sourced. This stays along the lines of our current packaging w/little modification and also stays in-line with .deb, .udeb, and .ipkg formates (the latter are reduced .deb formats). I would consider doing something like the PacketFilter 'mpg.lrp" package where saved conf files (or sic the global variable file) are saved. If loaded last, it overwrites the other packages conf files (or default values when appended to the global file) on re-boot. Food for thought anyway. > > o All the configurable files of a package must be collected. > > > > o All the variables in a package must be collected. > > You make the case for doing something along the lines > of what I thought of, namely creating .leaf packages > so that their configuration files have been modified to > use the db variables, which are standardized. Why cache the conf files themselves if the variables are already in place? Food for thought. > Chad Carr makes the case for: > > config-db > \ > \ > interfaced only by an API <------------ api triggered by new > packages \ > \ > templates of each package config file > \ > \ > dynamically created run time conf files, > > > > So I think there are two camps evolving in this discussion. > > Next you make the final point: > > o All the types of variables used in all LEAF distros must be collected > > and given a type name. > > I don't understand why this level of complexity is needed, > unless the XML-php dynamic web page creation thing is where > your idea is headed. As Mike Noyes can tell you, I sort of > anti-php, having been doing webmin stuff back in the days of > Netscape-0.96, before Windows httpds. I like to retain control > of how the page looks, which is slighty anti-the-concept-of- > markup-languages. Why a type? All the variables need is a value (and/or list of available values). These can be passed by hand-editing, script-file, menu, http/cgi, Java/Jscript and the use of 'sed'. <snip> > It's sourcable but still contains the glue. Would you > agree that using sourcable straight text config files > is a good system still used by Makefiles? Absolutely. I think any complexity should be added in the backend (ie... parsing). Delimiting can be done in a mutitude of ways (tabs, =, spaces, etc....). 'diff' and other shell commands could also be used in various usable ways to make backups of the variable file. Matt, you are more experienced with Oxygen than I am. Exactly how does David deal with this with his optional menu system? Use of 'apkg' itself isn't too crazy of a thought. -- ~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
