On Fri, 2003-02-07 at 14:15, Matt Schalit wrote: > > 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.
No problem. This is truly the next phase of leaf. I am glad to be a part. > >>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. > >>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. This is a different problem. It is up to the package maintainer to decide what people can and cannot configure via the web interface (and when I say web interface, I really mean non-editor interface, since other types of interfaces including SNMP may easily be built on top of this system). This is just like his decision to grant editor access to certain files through the lrcfg menu, just a little more advanced. > >>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. Yes. Bingo. > So how can we make a front-end that reads a package and creates > all the variable fields and choices dynamically? Again, a different problem. It is possible to create a _very_ dynamic web interface using a drop-in methodology and templating similar to what I am proposing, but we really need the infrastructure first. The same tools could be used. > Does every package need a manifest of all possible variables > and commands? Is that possible? Yes. For _complete_ configuration yes. Is it possible: not for shorewall ;-). But not really required for a web interface. Our competition on this front is linksys, dlink, microsoft, netgear, toshiba?, cobalt? You don't have to expose all the beautiful workings to the world. Just the most common. Advanced configuration has been and always will be by hand. When competing against cisco you need cli and snmp; for the rest you need web. > If it's not possible, where do we draw the line and say > that any more advanced config has to be done by hand? The package maintainer does this. He is the only one who can say what should be configurable in any interface. > > 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? Yes. As Inspector Clouseau once said "That is what I have been saying." > >>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. Thanks. -- ----------------------------------------------------------------------- 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
