All,
I started to draw this out, but I just simply do not have skills in that area. Some would question my verbal skills as well, but here goes:
Each of the tools (cdb, trig and tmpl) represents a data store.
cdb -> abstract configuration variables
trig -> abstract actions tied to those variables, with package-specific handlers
tmpl -> package-specific data allowing the creation of operational configuration files from abstract configuration data.
The idea is that an interface (of arbitrary complexity) needs only to know the abstract values (configuration parameters and trigger actions), and the packages can make themselves work.
It would go something like this:
1) The user chooses to configure his or her LEAF router via an interface (web, ncurses, etc.) backed by leaf-tools.
2) The interface makes one or more calls to cdb to obtain the current canonical values for a handful of (hopefully related) configuration parameters.
3) Cdb returns these values to the interface as "name=value" pairs that may be sourced via the usual shell script methods.
4) The interface draws some sort of user-friendly input device (probably a form of some kind) to display those values and allow the user to alter them.
5) The interface accepts the user input, then makes one or more calls to cdb to update the configuration data.
6) This data is inserted into cdb's backing store (whatever that happens to be!)
7) The interface "triggers" one or more system events by calling trig with the name of the event and optional parameters.
8) Trig runs the scripts that have "registered" for that event (by dropping themselves into the proper directory). The sequencing of this execution is controlled via leading index numbers (think SysV init scripts).
9) Each script decides for itself what needs to be done on each system event. Generally, this will involve reading the new values from cdb, rewriting its configuration files using the new values, then restarting or otherwise re-initializing itself
10) If any trigger fails, the cdb is rolled back to a sane state and the trigger is fired again, restoring the system to its previous state.
11) The interface displays either an error or success message. On success, the user is presented with a page offering to back up the system to the boot media thus preserving the state of the system across reboots.
Now, that is what is in my head, but as you can see, there are several points of contention that need to be discussed thoroughly. But, none of the points of contention have anything to do with the design of the backing store model. Frankly, it is a very small part of the overall design and, while cdb may not be perfect, it does work, quite well in fact, and it is done. I say we all take a look at it, stamp it with approval or disapproval, and move on to more pressing questions, like when to back up changes and how the hell to write a full-featured templating system in the 92k stripped down /bin/sh from Oxygen!
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
