Lynn Avants wrote:
On Friday 07 February 2003 07:23 am, Chad Carr wrote:
The api makes the hierarchy "feel" like name=value pairs. The output
from the api _is_ name value pairs; the input is sequential arguments
that mimic name=value pairs. See the following transcript from my CVS
code:
[ccarr@ginger leaf-cdb]$ ./leaf-cdb get tree interfs
default='eth0'
eth0_ipaddr='172.24.8.24'
eth0_netmask='255.255.252.0'
eth0_gateway='172.24.8.1'
Very nice structure and output, Chad. Thanks for taking the
time to work on this.
A properly designed api makes it easy to get and set "name=value pairs"
without actually having them in the same file. The strength in this
approach is that an individual package "owns" the data in the files that
map to its name=value pairs, and can be responsible for backup them up,
then putting the file back into place on the next boot. The file is
"assembled" rather than edited.
Who owns shared information between packages? There are several people
that have already hacked single file and/or single package configuration.
If the package 'owns' and 'stores' it's own db values, how is replacing
something like a dhcp client going to 'drag-n-drop' w/o requiring it to set/
configure itself. With the information stored in an configuration
file/package, you could reasonably assume that the same variables/values
are universally used between the similar programs.
Another thought, maybe too late, I was wondering how a package like
shorewall could take its parameters from a pure key=value db. The keys
would have to be very elaborate then and such a set up might be more
complicated to understand than the current one. Tom probably had good
reasons to split his configuration files.
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....
Your example of shorewall is very apropos. Shorewall will need to know
about nearly every networking change on the box, as well as changes to
it's own configuration. If a new interface is added, it must regenerate
its interfaces file and restart. If someone adds a rule, it must
regenerate its rules or policy files.
So it regenerates it's interface file, but what default rules or
policies does it apply to that interface? Does it NAT it? How
does it know you're not intending to bridge or traffic shape?
The complexity of this is staggering.
It is up to the package itself (or the folks who are trying to integrate
it with the web interface, I suppose) to interpret the event and make
the necessary changes to the configuration files.
The reason this must be is that if a web interface knows the results of
its actions, it must necessarily be bound to the implementation,
_inextricably_. Then if someone comes along and creates a fancy new way
to configure interfaces at boot time or a new, even tinier dhcp server,
the web interface would have to know about it to get it configured.
This is bad. I think.
Bingo. I was thrashing around this problem myself.
If I were making a GUI front-end configuration/admin program,
I'd have to hard code in every variable that a package uses
and make the drop-down list of possible choices and all that
in advance. If a package changes, I have to change the front-end.
Yikes.
Not only that, but I'd have to know how to issue the necessary
commands to configure every conceivable type of network hardware
setup. That's impossible.
So how can we make a front-end that reads a package and creates
all the variable fields and choices dynamically?
Does every package need a manifest of all possible variables
and commands? Is that possible?
If it's not possible, where do we draw the line and say
that any more advanced config has to be done by hand?
Ok, so now we're suggesting making the packages smarter. This follows
the logic since only the package can assume its use. It's a big step moving
responsibility from the front-end, back-end, and db-system to individual
packages. Logical or not, is this what we want to propose????
I'm not sure we could put the responsibility anywhere *but* into the
package, Lynn.
When you sit down to ponder making the front-end GUI, you realize that
it has to be future maintainable so that Joe Developer can drop his package
plugin onto the GUI and it appears with all it's vars. Holy cow. Is there
any other way?
This adds strength to the LEAF framework; a base from which to proceed
and a consistency for package maintainers to build upon. The key is to
build the complexity into the core components so that packages and
features laid on top become ever more trivial to implement. If making a
new package for Bering means writing a whole new subsection to a web
interface (which some folks don't know how to do) they will be less
likely to approach the task.
You are wise, Sir.
Regards,
Matt
-------------------------------------------------------
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
