The config-db is only itself. The templating system is used to transform the "abstract" values in the config-db to the format of each package.
Ok thanks for explaining how the template system is used here. Now why is that more useful than just modifying each packages conf files to use standard variables defined in a config-db?
Yes. It would then fire a trigger which tells the templating system to re-make its configuration files.
Wow, triggers. Very cool indeed. No more grinding my way through a bunch of places to find where I need to change the hostname or IP address. All dependant packages get reinitialzed with the new vars and restarted in the right order.
It should only be accessed through the api - data hiding, you know.
How big would the api be and in what language? How could we create one using the fewest functions, in the most concise and simple format in shell, and what would those functions be? (It's easy to feature creep later)
Also, the config db is not a simple shell fragment; it must be multiple files that can be "dropped" into a filesystem hierarchy then accessed as nodes or trees. This allows the representation of complex data structures such as those needed for defining routing, traffic classification, etc. The api must be very smart in the way that it delivers these data structures.
Ok. I'd prefer a single easy to read text file of name=value pairs. Regards, Matthew ------------------------------------------------------- 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
