[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [hyades-dev] Notes from HCE meeting Aug 19 about variables
|
Slight correction: the proposal was Antony's based on a need identified
by Scapa.
-----Original Message-----
From: hyades-dev-admin@xxxxxxxxxxx [mailto:hyades-dev-admin@xxxxxxxxxxx]
On Behalf Of Allan K Pratt
Sent: Thursday, August 19, 2004 10:13 AM
To: hyades-dev@xxxxxxxxxxx
Subject: [hyades-dev] Notes from HCE meeting Aug 19 about variables
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
_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev