David Schlangen : Home Page > minutes190607
- present: Timo, David
- test use case for development of agent communication architecture
(possibly on top of OAA):
- two agents take turn playing WAV files; when silence from one is
detected, the other starts talking.
- required modules / agents:
- "air", which simply multi-casts streams
- for each dialogue participant, "ear" (which buffers incoming
stream from "air"), and "mouth", which more precisely is the
interface between the DP and the environment.
- "mouth" (or "mair") is where the strict tact is
produced. Has output buffer which is connected to DP-internal
realiser (be that a WAV player or a TTS). At each time point
t = t-1 + (1 / sample_frequency * delay_factor) the mouth
sends out the topmost sample in the buffer, or, if that is
empty, a 0 sample (silence).
This is how time-pressure is created for the DPs whose ears are
connected to the mouth.
Note: delay_factor must be known to all mouths. Technically,
perhaps doesn't even have to be same for all mouths, but logically
it should.
Other important module:
- IS manager; module that manages information state. Other modules
can register triggers, in the form:
- if Condition, send trigger Trigger
where Condition can be a complex test on IS variables (with
different tests defined for different data types of
variables). E.g. "change(is/control/tt_state)" fires when the
value of the variable tt_state changes; "gt(.../threshold, 10)"
when ..threshold has a value greater 10, etc.
- this could be realised as follows:
- when IS manager receives a write request for IS field, it
blocks, executes write; goes through all trigger rules that
have conditions that mention this field, collects & sends out
triggered events.
[added 21/06/07:]
open issues
- can the modules of different DPs / agents be in the same agent community (i.e., use same OAA network / same facilitator), or would it be advantageous to separate them, and let mouth, ear and air communicate via sockets, externally from OAA?
- if all in same OAA network, must find mechanism to distinguish solveables of same module type as part of different DPs. (If facilitator is clever about conjuncts, each module could on start-up define solveable with name of DP, e.g. "Peter". If facilitator is clever about parsing queries, stg like "solve(peter, talk(X))" should then only be sent to the provider of talk/1 that is part of peter, even if there are other talk/1-providers.)
das, 06/21/07 08:33 (GMT)
Keyword: architecture,
inpro,
meetings,
minutes,
oaaAdd a new page under this one
