Thanks for the feedback, Antony, and thanks for keeping
the deadlock issue in view.
I just wanted to clarify the Client Data
(which I’ll also clarify in the next rev of the document). The Client
Data in the agent registry is meant only to be static metadata that will allow
the client to determine information about the nature of an agent before it is
created. There will be a separate mechanism for agent configuration (to
be described soon) that should address your concerns.
On the topic of server-to-server
communication, do we need that now? I put some allowances for it in the
protocol because it seems like something we definitely want sometime in the
future, but I have been thinking that we wouldn’t implement it in the
3.1/3.2/4.0 timeframe.
-Andy
-----Original Message-----
From: hyades-dev-admin@xxxxxxxxxxx
[mailto:hyades-dev-admin@xxxxxxxxxxx] On
Behalf Of Antony Miguel
Sent: Monday, June
07, 2004 3:49 AM
To: hyades-dev@xxxxxxxxxxx
Subject: [hyades-dev] hyades data
collection
Here are my comments on Andy
Kaylor's most recent Hyades Datacollection Protocol document:
- The "header expansion"
section with the size and pointer to an opaque field seems like a BLOB. The
point of the standardisation is to have compatibility and interoperability and
I think this will diminish that. If we want routing information and
security tokens I think we should build in places for them.
(also - we never discussed this
properly but if we're routing messages between servers then we don't have
a tree structure for the flow of messages any more and we really need some of
the deadlock protection Mike was on about a while ago)
- The name-value pairs under the
Client Data section of the registry seems to be the primary method of
configuration for the agent or at least for discovery of configuration
parameters. I would like to see the configuration of agents wrapped up
into some typed variable system with dynamic discovery of individual agents'
configuration variables rather than having a static set of varibles for each
agent type in a registry (although a number of static variables could be
provided in the registry along with the dynamically discoverable ones).
Typed variables can be more easily exported to a user interface or
a generic behaviour than name value pairs. Also, having agents be
able to publish further configuration variables at runtime means they can
publish context-sensitive configurations - if the agent is used for
monitoring X then it can publish variables which configure it relative to
that specific instance of X.
----- Original Message -----
Sent: Tuesday,
June 01, 2004 5:42 PM
Subject: RE: no
hyades data collection call today
Kim and Anthony,
I talked to Richard.
Basically, we should go
ahead and have the meeting at 1:00EST today (10:00AM PST).
The passcode is the same.
We are looking forward to
talking to both of you and getting your inputs.
We can talk to Richard
separately during this week or the next meeting.
Regards,
-----Original Message-----
From: Kim Coleman
[mailto:kcoleman@xxxxxxxxxx]
Sent: Tuesday, June 01, 2004 9:02
AM
To: Kaylor, Andrew
Cc: Nguyen, Hoang M; Victor Havin
Subject: no hyades data collection
call today
Sorry for the very late notice. After what happened last week, I thought
I should check with Richard this morning. He has a personal emergency to deal
with - a large tree fell on his car and his neighbor's garage last night - so
he isn't going to be available. Also, it seems the Hyades management meeting
has snarfed up our con call slot again, thanks to the holidays.
So it
is a skip for today. Perhaps we can try getting together on a different day
this week - that's one you'd have to take up with Richard. My schedule is
pretty open, but his never is. Richard says not to give up on him! :-) I just
started reading your latest protocol doc and will get any feedback I have to
you before I go on vacation (6/4-6/13).
-Kim
Kim Coleman
PurifyPlus Development
IBM Rational Software, Cupertino, CA
(408) 863-4094 (T/L 560)
kcoleman@xxxxxxxxxx