>
> 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.
We may well want to expand the visibility options. I am thinking
primarily that it will be useful to distinguish between read and write
visibility. For example, most "system" data kept by the facilitator
(like names and addresses and status of various agents) should probably
be only readable. We don't want thing to get too complex, but how about
having 3 values: private, readable, writable. (Writable of course means
readable and writable.)
> 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'
Very minor point: For boolean parameters, instead of having 2 distinct
values like single_value and multiple_value, why not have a single value
with one arg. So, it would be single_value(true) or
single_value(false). As a convenience, if desired, the true form could
still be abbreviated as just single_value.
> 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.
This is all great. I can see how these (and other) params will be
extremely useful.
>
> 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.
I'm still debating whether it's best to treat solvables and data as
separate things, as you are proposing, or as one unified sort of thing,
as Prolog does. But if we treat them as separate, what's the best
characterization of the difference? Procedure vs. data? If so, maybe
we now know what to replace the term "solvables" with: we now have
"procedures" and "data" declared 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...
First, since agent data capabilities have been redefined, I assume we
need to revisit the definitions of data triggers. Until now, data
triggers have only applied to the facilitator. They will probably
generalize nicely to accomodate your new data proposals. But my main
concern is, it's confusing to have both data triggers AND
oaa_AppDataChange handlers. I think the oaa_AppDataChange handlers are
probably subsumed by data triggers, so we just need to make sure data
triggers are sufficiently general, rather than introducing a new
category of handlers. Does this fit in with your thinking?
- Dave