- Replace bb predicates (read_bb, write_bb,...) and generic
database agent (db.pl) by integrating data management into
all agents through new db primitives in the agent library.
- Database management will closely parallel event management,
with something like a solvable list kept by the Facilitator
about data types for each agent, and a do_event-like data handler.
- Will support replication for simple collaborative activities
---------------------------------------------------------------
Now that we have had a chance to discuss triggers and events,
the next subject on my list is Data Management.
As you know, the current OAA system uses read_bb, write_bb, etc.
as a way of maintaining a global data store on the Facilitator.
This is useful for several reasons:
- An agent can post information (for example, status information)
to the Facilitator which can be queried by other agents using
Solve, without the first agent needing to be directly queried (and
interrupted) by a standard solvable call.
- Because of this, frequently accessed information can be made
available to the community by posting it to the Facilitator, which
reduces network overhead when accessing the info.
- After inspecting some information available as data on the
Facilitator, an agent can install a data trigger requesting
automatic notification if the value ever changes. This is much
more efficient than constant polling using solvables.
The current OAA system makes use of a special generic database agent
(db.pl) to hold supplementary information for agents. This database
agent provides solvables such as db_declare, db_assert, etc., allowing
agents to add, remove, change and query data predicates, as well as
set data triggers on the information.
My proposal is to integrate the database primitives provided by the
db agent into the agent library of all agents, and to remove the
read_bb, write_bb primitives altogether. Agents could now keep
local databases, or install data and data triggers on any remote agent
including the Facilitator. In addition, the write_bb only allowed
predicates with ONE argument to be maintained by the Facilitator
(such as user_name('Adam Cheyer')). The new system would work with
predicates of any arity.
We would not add versions of the db agent's solvables as primitives
in the agent library:
oaa_DbDeclare(DataPred, Arity, Params) where params could include:
address(A): by default, data is managed by local agent, but with
address(parent), data will be managed by Facilitator,
as was done using write_bb.
visibility(V): by default, visibility will be 'public': other agents
can access and query the data. If V is 'private',
the data is just for use by the local agent.
lifespan(L): if L = permanent, data is saved to file when agent
quits, and reinstated the next time agent restarts.
if L = temporary (default), data values die with the
agent.
If the data is installed on a Facilitator, when agent
quits, the data will be removed if temporary, and
kept if permanent (see Trigger Management msg).
single_value: any db_assert will overwrite any previous values
default is 'multiple_value'
no_duplicates: at most one copy of each value will be stored.
default is 'with_duplicates'
shareable: Predicate will use replication among to allow
collaboration among multiple participants (see below)
and others!
oaa_DbAssert(DataPred, Params)
oaa_DbRetract(DataPred, Params)
Plus more primitives for Loading, Saving, Simulation, etc.
Data can be queried using the standard oaa_Solve predicate,
and perhaps also by an oaa_DbSolve, which first checks local database
before sending out communication requests elsewhere.
Data management will come to parallel that of event management.
In the same way that we have a solvable list of goals for each agent,
db_declare will add to a data_manageable list of predicates for each
agent. When a db_assert primitive is executed, the Facilitator will
find the correct agent(s) who manage this data type and tell it to
add the information to their data store. Data triggers will act in
the same way.
In a similar way to how a oaa_AppDoEvent() handler is defined for
each agent SOLVABLE, an oaa_AppDataChange() handler can be defined
for each DECLARED data predicate. Let's use an example. Say an
add_icon(X,Y,IconType) event has been defined for a map display agent.
The do_event predicate will record the state change (that there is a
new icon), and then visually update the screen to reflect the change.
The old way of programming this might have been:
% given an event to add a new icon to the display,
% add the icon to the list of visible icons and then draw it.
do_event(_KS, add_icon(X,Y,IconType)) :-
assert(visible_icon(X,Y,IconType)),
draw_new_icon(X,Y,IconType).
Now we will use:
oaa_AppDoEvent(_KS, add_icon(X,Y,IconType)) :-
db_assert(visible_icon(X,Y,IconType)).
oaa_AppDataChange(visible_icon(X,Y,IconType), asserted) :-
draw_new_icon(X,Y,IconType).
db_assert will add the data to the local database, and then call
the event handler for the change. What's the advantage?
Now, if the visible_icon predicate is declared 'shareable',
when the data predicate changes locally on one agent, other members
of a collaborative conference will synchronously receive changes
to the shared predicate, and the data handler will be called,
drawing the new icon on everyone's screen. The actual means of
propogating the changes can be hidden by the architecture,
and be based on SCOOT or other collaborative techniques.
So, as usual, remarks, comments, suggestions and criticisms
welcome!