Hello Chad, I really think we were miscommunicating,( we have different background ;) ) but I'll try again > >
Packages Packages own templates of their configuration files or scripts to generate those packages ( even better) Packages own several variables ( necessary to configurate the package) The values of this variables are stored in a database A) Some of the variables are only used in scripts of this specific package ( f.e ppp0_dialnr) A change would have an effect only on this package B ) Others are used in several packages.(for.example eth0_ipaddress) a change to one of those would effect several packages A variable and a package cannot know if it ( variable) belongs to group A or B (someone could have added a new package that makes a variable belong to more than one package). So to be on the safe side, assume all packages belong to group B) The variable must know the scripts it is "tied to" The database is assessed only by a config-db api that reads and writes a "key" or a "tree" Some userinterface ( for example webinterface) requests variables from the database and uses them to create a webpage based on a script belonging to a "userinterface-script pool" . After input by the user, the now possible changed variables (in userspace) are presented to the config-db to be set in the database. (config-db.set var1 var2 ...) Now it is necessary to "commit" this changes so the config-files are still in sync with the database. At commit the config-files "tied-to" the changed vars are regenerated After change of config-files the belonging services are restarted. I think untill now we are communicating the same infrastructure. My proposition was to create a database in the same tree structure variable /tied-toscrip1.name (content script to run after changeing tied- toscript1.name) variable/ tied-to sciipt2.name (this was my "dependant" database. example #ls eth0 eth0/etc/interfaces eth0/etc/shorewall/interfaces #cat eth0/etc/interfaces ifdown eth0 ifup eth0 # cat eth0/etc/shorewall/interfaces shorewall restart (<optimizing > ) after changeing a variable drop the tied-script.name s in a queue after finishing the interaction user <-> interface update all scripts in the queue These commits can be queued untill the end of the user configuration session ( so after making 3 changes the sripts don't have to run 3 times) (</optimizing>) > - then I back myself up (heh. I don't know the intimates of how > this one is done, Mr. Wolzak) How, will depend on the packageing system to choose uptill now it will be lrcfg.back.script with some options. > > I am obviously not getting what you are saying here. Please elucidate > further. Please keep in mind that I am only speaking of the framework > and infrastructure here, and not in detail on the specifics of the web > interface. We need a firm concept and toolset before we start webbing! this is a misunderständing, I mentioned the webinterface to show one way of user interaction. I suggested that each package contains a file with the 1. names of the used vars 2. type of the vars ( to make it easier for the user interface) 3. possible values ( if a var can have only three different options ) the idea behind is to make the system of "validating changes" and presenting to user easyier We need only a few routines in the commit section that checks a value and can be used by each script that adaps config files. used as toolset. I thought about it as I was still considering that a script to create a config file would look like # this is xyz config $dev $ip_address # the hostname is $hostname $dialyesno dial $dialnr $option_1 $option_2 But the template script probably would be better in a form #!/bin/bash writecomment this is xyz config write $dev $ip_address write_if_set dial $dialnr writerepeat $option in this case that information is in the template script, a gui script could then easily be analog. Sorry dreaming above the infrastructure ; ) regards Eric Wolzak member of the bering crew ------------------------------------------------------- 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
