On Sat, 2003-02-08 at 02:04, Eric Wolzak wrote: > Hello Chad, Matt Lynn and list > > first of all my compliments for the programm ( much cleaner as what > I did ;) ) > two small comments > 1) to set a variable it should be set like this > leaf-cdb set eth1/ipaddress 192.168.1.254 > but the syntax > leaf-cdb get eth1 > returns eth1_ipaddress=192.168.1.254 > > isn't it more intuitive to set > leaf-cdb set eth1_ipaddresss 192.168.1.254 ?
Perhaps. 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. > 2) > 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? > > > >>The interaction between the config-db and the trigger/templating system > > > >>is a pure abstraction. The name=value pairs on the output of the api > > > >>become the input (and symbol table) for the template. With a properly > > > >>designed templating system _any_ type or number of files can be > > > >>generated, data can be morphed or manipulated after it leaves the > > > >>config-db (i.e. netmask could be transformed to netbits or vice-versa). > > > >>The work flow is: > > > > > > So all the complex coding is in the template that comes > > > customized with a package? Is that system that has to > > > know all the different brg commands for bridge.lrp for instance, > > > so that it can make the correct bridge.conf type of files and > > > issue the correct "ip route ..." commands and the like? > > > > > > > > > You touched on the reason why this is so important > > > to figure out in advance, down below.... > > > Even the init script for a package may be templatized, if it relies > > heavily on command line parameters and conditional setup behavior. > > _Any_ file on the system that is required for functionality of the > > package may be customized. > > 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. > > rm filestochange > #put the changed templatenames in a file > while changeing > do > change_a_var > for i in changedvarname/* > do > echo $i >> filestochange > done > done > for files in `echo $filestochange |sort |uniq ` > do > fill_templates $files > done > Release changeing flag 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. > My I idea is to put the issues that can be edited as variables in the > template combined with some logic. > The options that are not free to edit for the Joe Average are > hardcoded. > Pete Poweruser could then edit the template to change things. Yessir. > 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. > ---------------------------- > and a define etc_hosts.def > which > 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. > 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. -- ----------------------------------------------------------------------- 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
