[hyades-dev] Notes from HCE meeting Aug 19 about variables

[Allan K Pratt <apratt@xxxxxxxxxx>]

These are Allan Pratt's notes from the HCE (agents and data collection) 
meeting of Thursday, August 19 2004

Attending:

Antony Miguel from Scapa
Andy from Intel
Luc from Compuware
Allan from IBM
Hoang and somebody from Intel

Topic: Andy's proposed variable system

Andy created this proposal because Intel saw the need to set the frequency 
of data collection. Also, he saw that the choreography layer wants a 
variable setting capability. He saw that it would be better to have just 
one WSDL interface and one binding to address multiple agents, rather than 
having each agent handle variable settings in a proprietary way.

By exporting variables and their descriptions, it becomes possible to 
create a generic UI that lets a user drive an agent by interpreting the 
variable names and values. 

In addition, it might be valuable to reserve some variable ids for 
predefined use, such as "frequency of data collection," that would permit 
nonhuman agent drivers to get value from arbitrary agents.

Since these are typed, not just strings, the UI can be a little more rich 
(checkboxes for booleans).

With the XSD type you can have the generic UI lay out complex types, or 
even have extension points in the UI so an agent provider can supply a 
plug-in that customizes the UI for his XSD types without having to write a 
full-blown custom UI from scratch. 

We discussed the fact that this variable system has almost all the 
capabilities of the "property" system, and there is no need for both. 

We decided to abandon the "property" system, replace it with this variable 
system. We decided to include this variable system in the base agent 
interface, rather that put it in a separate interface. An agent that 
doesn't have variables can return "none" to all queries and "failed" from 
all gets and sets.

What about the property bag? This is a capability in the property system 
that is missing from the variable system. We need to define an API for 
setting the values of a group of variables all at once. The purpose is to 
save network bandwidth and turnaround time, and also to be able to set 
combinations of variables to consistent settings, to avoid inconsistent 
states.

Then again, if it's possible to have inconsistent states, there is no way 
to prevent a user from entering those states by setting individual 
variables to inconsistent values.

Andy asked about hierarchical variables. The generic UI that presents 
variables will want some guidance on how to lay them out. The API needs a 
new call to get layout guidance.

We discussed attributes that variables might have, beyond their id, name, 
and type. For example, some variables are read-only; some are writable 
only before data collection starts, or only while data collection is 
paused. Others are read-write any time. The API needs to grow to define 
attributes like this and permit a client to query them.

Since we're designing a generic UI as a castle in the air, Allan mentioned 
something he would want in that UI: buttons which, when pressed, send 
asynchronous commands to the agent. For example, "take a snapshot now." 
This is a common thing that lots of agents have to provide custom UI for. 
Perhaps the layout guidance can include descriptions of buttons, their 
labels, their descriptive text, and the actions they should cause. I think 
this means the agent API needs a generic "button with id X was pressed" 
command as well.

Regarding our process here, Allan suggests that we record the outlines of 
the generic UI we're envisioning, so the ultimate UI writer has some 
guidance as to what we were thinking.

-- Allan Pratt, apratt@xxxxxxxxxx
Rational software division of IBM