[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hyades-dev] hyades data collection

Hi Andy,
The Client Data sections sounds fine then (is it just like a properties list for an agent type?).  As far as server to server communication, I don't think we need it now but thats one of the reasons Hoang gave in your document for the opaque data field in the header section.  What I was trying to say was if we need things like routing and server to server communication (and security tokens) then we should build proper placeholders into Hyades (whether its now or in the future), rather than have an opaque field that people can put potentially important but non-standard data into.
Antony Miguel
Scapa Technologies
+44 131 550 1766
----- Original Message -----
Sent: Tuesday, June 08, 2004 5:28 PM
Subject: RE: [hyades-dev] hyades data collection

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.




-----Original Message-----
From: hyades-dev-admin@xxxxxxxxxxx [mailto:hyades-dev-admin@xxxxxxxxxxx] On Behalf Of Antony Miguel
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.




Antony Miguel
Scapa Technologies
+44 131 550 1766

----- 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.




-----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 Coleman
PurifyPlus Development
IBM Rational Software, Cupertino, CA
(408) 863-4094 (T/L 560)