Notes from the Hyades Data
Collection Engine meeting for 8/5/2004
Attendees:
Intel
Andrew
Kaylor
Hoang M.
Nguyen
Karla
Callaghan
Vishnu
Naikawadi
Srinivas
Doddapaneni
Compuware
Don
Ebright
Luc
Plaetinck
IBM
Kim
Coleman
Hoang introduced Sri as the latest
developer joining the effort from the Intel side of things.
We reviewed the Hyades Protocol
Specification document (Rev. 0.5), beginning with the Agent Manager
interface.
**Important**
At the end of the meeting, Andy
requested that this be the last review of this protocol specification document
and that from here on out we will discuss only changes and additions to the
document and otherwise assume that the document as it stands will form the
basis of our implementation. If you have concerns about this, raise them
now.
The "Agent registry" will probably
be implemented as a series of XML files deposited in "Metadata" directories
under agent directories in the HCE installation tree (following the config
model in Hyades 3.0). The precise details of how this will be structured
and what will be contained in the metadata needs to be fully documented
(soon).
We discussed the reference
counting scheme and noted the continued need to incorporate details as to how
agents may keep themselves around. The topic of bound vs. unbound agents
was also mentioned as something to be included in this document whereever
needed.
The distinction between
CID_QUERY_AVAILABLE_AGENTS and CID_QUERY_RUNNING_AGENTS was discussed, and we
agreed that it will not be necessary for clients to use both. The two
options are provided for flexibility.
We discussed the fact that
CID_QUERY_RUNNING_AGENTS is intentionally non-specific. It is up to the
client and agent to negotiate further details, such as the agent's name, any
process it is bound to, etc.
We discussed the fact that the
data returned by CID_GET_AGENT_REGISTRY is cacheable. In the first
implementation, this data will not change at runtime. If it does in the
future, an event can be added to notify the client of such
changes.
The distinction between getting an
agent reference and attaching to an agent was discussed. It seems that
the precise behaviors involved might need to be clarified.
It was noted that the description
of the CID_REGISTER_AGENT command doesn't indicate where the Agent ID came
from. That needs to be documented.
We talked about whether it would
be possible for an agent to de-register itself and shutdown if a client is
attached to it or has a reference to it. I believe that such should be
possible, and we need to have a mechanism for notifying the client when this
happens. The agent should only do this when necessary.
We also discussed the need for
robust error handling in the case where an agent goes away without
deregistering. It was agreed that the protocol specification can insist
that agents must deregister, but the implementation needs to gracefully handle
the fact that this won't always happen.
I believe that a general document
on error handling strategies is needed.
We discussed the event listener
handling and the fact that this will become a separate interface to define
system wide event behavior.
At next week's meeting we will
begin reviewing the base agent and collector interface
specification.
