Re: Loopy Triggers

Adam Cheyer ((no email))
Thu, 03 Dec 1998 08:24:08 -0800

Stuart Lowry wrote:
>
> I have a two part question regarding the "constraint" on the trigger API
> that I hope someone can help me with. I am writing an agent called
> 'trader' that sets a trigger to capture all events. I am filtering out
> my own events as the constraint to avoid a continuous loop. My problem
> is that there may be other agents that set Triggers to capture all the
> events like too (like a "monitor").
>
> I am setting the constraint like the following:
> constraint = "(KS\\== trader )";
>
> question a/
> How do I include more than 1 KS to constrian...I tried the following
> with no luck: constraint = "[(KS\\== trader ),(KS \\== monitor )]"; but
> that did not work.

You could write the constraint as

"(KS \\== trader, KS \\== monitor)"

> question b/
> Fortunately my trader knew about an agent called "monitor" that was
> setting a similar trigger. Is there a rule of thumb that agents like
> these should advertise themselves as a type of "class" and that the
> similar agents can filter out events that originate from this similar
> class of agents?

Good question!
This is a rather new problem that's been raised with the advent of the
monitor program (the first agent that has really done much with event
triggers),
and I'm not sure the best way of handling it yet. I'm open for
suggestions....
My initial thought is that in OAA there should be a way to either
explicitly or
implicitly send events which are not trapped by event triggers. For
instance,
maybe every event produced as the result of a event trigger firing
should NOT trigger
other event triggers. I think I prefer explicit programmatic control as
well,
allowing a programmer to override the default of whether triggers fire
or not.

// Agent will receive an update_event() message every time
// any agent sends or receives any message (useful for logging).
// Note the parameter evt_triggers(false) so that the update_event
// message will not try to trace itself.
Java: oaa.lib.addRemoteTrigger("event", "whenever", // Type &
recurrence
"Op", "event(AgentId,Ev)", // Condition
"true", // No additional
test
"post_query(update_event(Op,AgentId,Ev),[broadcast,
evt_triggers(false)])");

Note, the above parameter (evt_triggers(false)) is not yet implemented,
just
a proposal.

Maybe such a scheme should include classes of events, or maybe
priorities
that allow higher-level requests to again override lower-level
preferences.

Any of these ideas will require modification to the agent library and
recompilation
of the Facilitator, but I'm certainly looking for comments or
proposals. I'd like
to incorporate something that handles this problem into a new version of
an OAA 1.0
facilitator so that we can test it, smooth out any problems, and then
incorporate
this in OAA 2.0.

-- Adam.