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

Reply via email to