Thanks for the
feedback, Antony, and thanks for
keeping the deadlock issue in view.
I just wanted to
clarify the Client Data (which Ill 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
wouldnt 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