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.