I like these proposals, they seem quite general, and they have obvious
advantages over the current system.
But they do bring up one general concern, which is that an agent is
extremely vulnerable to misguided or malicious control events arriving
from other agents.
This the case not only for requests for flushing of queued events, but
also for requests to add and remove triggers (as discussed in other
messages).
Intuitively, it violates an agents "sovereignty" to have that agent
automatically comply with all flush requests and trigger requests. And
when OAA gets out into the real world, the vulnerability to misguided or
malicious programming could quickly become a serious concern.
I don't have a clear answer to this. But perhaps something simple would
go a long ways. Perhaps one of these:
(1) Each agent could specify from which other agents it will accept
event flushing or trigger requests.
(2) When an event flush or trigger request arrives, it could be handled
by a locally defined handler, if one has been defined. Such a handler
would give an agent developer a place to write code to verify that it
makes sense to comply with the arriving request. If the handler is not
defined locally, then a default handler, provided by the agent library,
could be used.
- Dave
Adam Cheyer wrote:
>
> Hi Everyone,
>
> Here's my vision of what events will be like for the
> released version of OAA. Although this is what I have
> implemented so far, it is still malleable, so feel free
> to comment on what you like or don't!
>
> ===================================================================
> SUMMARY of PROPOSAL
>
> For those who don't have time to read:
> the new version will add priorities to events, add flexible
> event queues, and change the default behavior for events
> received during a blocking solve.
> ===================================================================
>
> If we are doing a blocking solve and waiting for the solutions
> to return, when some unexpected event arrives, what do we do?
> In the current OAA framework, we try to execute this event, because
> the event might be an important message, maybe even a message
> saying that we should abort our current polling for the event.
> If we deferred execution of this event until later, an abort-style
> message would be taken into account too late.
>
> However, this can cause some problems, especially if the incoming
> event triggers work that requires another blocking solve.
> Now we have nested, recursive calls, and we are waiting for
> two different sets of solutions. Current OAA libraries have
> had some bugs related to this behavior (one problem regarding
> out-of-order return of solutions has been fixed in the Prolog
> agent library by the way, so grab the latest copy...)
>
> So, the proposed fix is to add priorities to incoming events:
>
> oaa_PostEvent(Event,Params)
>
> can now take parameters :
> address(Dest) : [Optional] Agent to send the event to
> priority(P) : [Optional] Priority of event
> (P: 1-10, 5=default, 10=high priority)
> flush : [Optional] flush lower priority events from queue
> (see description below)
>
> Priority and flush are also added as parameters to oaa_Solve().
>
> By default, if waiting for solutions in a blocking solve, unexpected
> events arriving will be queued for execution until AFTER the solve
> has completed, UNLESS the incoming event is of higher priority than
> the currently blocking solve, in which case it will be executed
> immediately.
>
> Another problem that is fixed by this scheme is as follows:
>
> Say requests come in to an agent faster than the work can be
> performed (for example, a text-to-speech agent might take several
> seconds for each request to complete). In this case, incoming
> events and solve requests will start backing up. Well, with
> priorities, you can send an event which will jump to the
> head of the line of executing events and be executed immediately.
> If a high-priority event is combined with the "flush" parameter,
> as the incoming event moves ahead of queued lower priority events,
> it removes them from the queue! Why would we want this?
> Well, in above example, we might want to indicate that all the
> backed up speech messages are no longer relevent, so the TTS
> agent should forget them, resynchronize to the current moment,
> and start saying things about the current state of the world.
>
> So, priorities are useful not only during blocking solves, but as
> a way of detouring (and even clearing) a backup
> of events not yet handled.
>
> So, as usual, comments or suggestions are always welcome!
>
> Adam.