Chad and list, Are the triggers asynchronous or synchronous? I imagine triggers can be used for semantic validation across packages and take appropriate decisions. If it does come to an irresolvable state, then errors have to be directed back to the initiator. From my limited knowledge, this would mean the triggers should be synchronous. The other problem with synchronicity is that we run the danger of hanging in case the trigger misbehaves.
The key is to have errors trapped neatly inline and fed back to the initiator without passing control back till a exit status is passed back. This will be particularly so for CLI where errors need to be reported immediately. IMHO, we need to support both. Actions like notification can be asynchronous while some others that need to be synchronous can be so. The program that registers the trigger would create it as a synchronous or asynchronous trigger. Some features that I think will be useful in this infrastructure layer (IMHO for a good UI/config system): 1. Commit and rollback of configuration commands. 2. Syntax verification and command completion. We can also conceive of the CLI being constructed and compiled into this DB. Syntax validation happens using this infrastructure. AFAIK, Zebra does the routing code CLI validation this way. In the Zebra code, we can load plug-ins for any module we want and only those commands are usable. This way, we can remove the need for bash shell for users and make the CLI shell as his UI. AFAIK, Zebra, suing this mechanism, filters options as the CLI is being entered apart from providing completion (hitting tab) and options (on hitting ?). 3. Use this DB infrastructure to maintain some key counters from the /proc interface to get a historical view. 4. Create a notification engine with API as part of the infrastructure that can be configured to use different notification mechanisms. Maybe syslog itself can be modified to handle this. Applications can use this API for notifications. 5. A well defined error reporting mechanism/ codification also part of the DB to make sense of error codes passed by called programs via triggers. Hope I have been lucid enough. Regards Mohan > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chad Carr > Sent: Tuesday, July 06, 2004 2:22 AM > To: [EMAIL PROTECTED] > Subject: Re: [leaf-devel] Source: config > > > On Jul 5, 2004, at 1:24 PM, Erich Titl wrote: > > Your analysis is convincing, especially as it covers the most > > important part of getting the system configured the way the > user wants > > it. > > My suggestion to allow the inverse way was wrong in the way it was > > formulated. I would actually love if the UI showed the > _actual_ state > > of the system. regardless of the config files, because the end user > > will typically also use such tools to check the actual > system status. > > If this is consistent with the system status at load of the UI we'd > > have a good starting point. > > Whenever a change is confirmed in the UI this state should > be written > > to the config database _and_ the system which would keep us in a > > consistent state. This would, of course, require quite a > sophisticated > > control mechanism, e.g. when the user changes an IP address, > > subsystems like shorewall and ipsec would probably have to be > > reconfigured and restarted. > > The purpose of having "trig" is to handle system-wide > notifications of cdb changes for just this purpose. The idea > is that the user makes a configuration change in the cdb, > then the UI calls a predefined trigger method for that > change. Any package that needs to know about that change > "registers" for the event by dropping a shell script in the > proper directory on the system, which is called when the > trigger fires. > The package can do whatever it wants in that script, up to > and including rewriting its configuration files, setting > other cdb variables, restarting dependent services, etc. > > > Hope this makes sense. > > It does to me. > > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- 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
