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.