Hello Chad > I am game for writing code that will accept any hierarchy > delimiter and allowing folks to use any of them. My preference is > actually '.' but it is not a proper character in a shell identifier. I > do think that the '_' doesn't properly emphasize the "path" or "object" > nature of the hierarchy access. But like I said, I am game for > anything. agreed ( I like the _ because I don't need somuch escape signs ;) )
> > if a tree exists eth1/ip/mask then it is impossible to create a > > eth1/active > > I can't replicate this. Can you give me a screen shot of your terminal > session? Neither can I anymore, tomorrow I got the problem, but probably there was something different corrupt in the database Now it functions. I cannot replicate it. > > > > what I did was create a tree dependant which a structure > > varname/dependanttmplate1 > > varname/dependanttmplate2 > > etc. > > > > The trigger to any action is the change of a variable > > allthough it shouldn't be trigger each time a var is changed but first > > after the complete change is ready > > So my idea was set flag I am changeing. > Locking or update atomicity is a different issue than triggers. They > should be addressed separately. The trigger handlers are just a > methodology for notification of a system event so that anyone may react > to the event, anonymously. The idea behind the database is that we can configure the box by communicating with an api by way of for example a webinterface Each time a webpage returns changed vars then the real config files aren't in sync with the database anymore. So all configs which templates contains the changed variables should be updated. What I ment is that IMHO it isn't a good idea to update all the config files during an editing session. Remember the vars or the files that contain them. And after the editing session is finished update those config files by filling them with the variables. We can of course save us some accounting by updating all config files. ;) It depend on what is faster. thinking a loud now I realize that we are creating a kind of OOP language structure. (correct ? ) In that case it could be usefull too write the system in a UML like description. :) A package has one or more configuration scripts that have one or more configuration parameters, Those parameters has several properties it has one or more values it has a value type it has 0 or more repetition So the whole configuration could be looked at like a tree. The problem is now that a paramter can belong to 1 or more packages. ( makes it complicated again :( ) > > We could have a configuration-template > > for example /etc/hosts has etc_hosts.tpl > > $host_ip $hostname > > Actually, it is even easier than this. There is a template root sibling > to the cdb (/leaf/tmpl) and any system file that needs to be templated > may be dropped in relative to its final path on the system, i.e. > /etc/hosts template goes in /leaf/tmpl/etc/hosts and templating program > automatically finds it and writes it to the correct place. how do you find which file has to be updated grep "changedvarname" /leaf/tmpl/ ? the api doesn't know who (which file) put the variable in the database. If you search all templates with each change you could have a problem with the performance on low performance systems ? > > 1) lists the used variables and the type > > type means here > > string > > value > > one out of optionx|optiony|optionz > > optional value > > > > and a default value. > > varname type optionstochose default "helpfull name" > > eth1_ip N - 192.168.1.254 "IP Address" > > > > a (web) interface could easily pick this up and almost automaticaly > > create a webpage. to edit this var. > > Yes, but we may want to create a hierarchy for this purpose and use the > same tools to avoid parsing another format. OK What i wanted to say, but wasn't clear for myself yet is that a line with vars could have a repeat property. > > 2) Aktion to take after the script is updated > > ----------- > > eventuall an package own database. > > this is included in the real database, but if values in the database > > exists they are not replaced . If you don't need new values, then you > > could extract the data also from the "define script" > > but The central database wins. > > This is the way to implement vars that are not there yet ( for example > > after an update, or a change to a new package or a change by Pete > > Poweruser to his templates. > > You don't really need this since a package can drop in its own variables > conditionally anywhere in the hierarchy he wants. He can put his own > tree under there if he wants. You are right. > 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