On Jul 5, 2004, at 9:58 PM, S Mohan wrote:
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 simple way is synchronous. Unfortunately synchronous is generally slow, and, as you mentioned, a way for an ill-behaved trigger script to make a mockery of the system.
A decision that must be made, and soon.
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.
It is possible to use cdb as a message board for asynchronous programs. Each trigger could be called with the name of a key array to write errors to. This array could be checked after completion for errors prior to committing changes. This allows progress of triggers to be timed out, but still have good communication back to the caller.
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.
1. Much needed discussion
2. Very fancy and nice. Have thought of this often. Beyond my time constraints right now.
3. Great idea. See, folks already coming up with novel uses!
4. Trig should be able to be used for this, but perhaps you were thinking of something lighter. We should discuss in more depth what you want from this facility.
5. See above (cdb as message board)
Hope I have been lucid enough.
Crystal clear.
-------------------------------------------------------
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
