I still prefer
integers for variable IDs. Hyades global IDs can be provided as defined
constants which provide nearly the same effect as a string name, and an offset
constant can be provided to specify the reserved range. I just think
integers are much more convenient to work with, and if we use strings theyd
end up being converted to IDs somewhere, possibly at both ends. Im not
concerned with performance so much as a simple programming
model.
-Andy
-----Original
Message-----
From:
hyades-dev-admin@xxxxxxxxxxx [mailto:hyades-dev-admin@xxxxxxxxxxx] On Behalf Of Antony Miguel
Sent: Friday, August 20,
2004 9:27
AM
To: hyades-dev@xxxxxxxxxxx
Subject: [hyades-dev] Choreography HCE
Requirements
I have a few of points for
discussion before I send round the next revision of the Choreography HCE
Requirements document.
- Integer variable IDs Vs String
variable IDs
On reflection, I think that we are
probably better off with String variable IDs than int variable IDs. It
provides us with a more intuitive way to specify Hyades-global variable IDs
(e.g. "org.eclipse.hyades.datacollection.frequency") and to reserve a range
(e.g. everything beginning with "org.eclipse.hyades"). I think this
makes it easier for people writing agents as they don't have to worry about
arbitrary integer bounds and bounds checking - all they need to do is use
their own domain for their own variables (e.g. "com.scapatech...") and check
for the names of only the generic variables they use. Also, I think the
performance hit we take for variables having String IDs is relatively minor -
we aren't expecting for variables to be set so frequently as to cause
performance problems (as far as I know).
We want some way to group
variables and to organise hierarchical structures of these groups. The
two ways I can see we could do this are:
1. use complex objects to
represent variables and variable bags
void VariableGroup
getRootVariableGroup() (returns a
hierarchy of VariableGroup objects)
void String[] getVariableIDs()
void Variable[] getAllVariables()
void Variable getVariable(String var_id)
...(and then just have fields + methods on the Variable object for id, group,
type, semantics etc)
2. have methods for group and
hierarchy discovery
void String getVariableGroup(String
id)
void String getRootGroupID()
void String[] getGroupChildren(String
groupID)
void String getGroupName()
void String getGroupDescription()
(Note that I would think the
Variable object here would NOT store the value or be used to set the value, I
think we should retain the "setIntegerVariable(...) etc" methods for
manipulation of a variable value. This means we're only using the
classes for structure and metadata, not for access)
My personal preference here is to
use complex objects, I think they're more clear and more efficient. Some
concerns were raised about using complex objects across different languages
but I think that we just need to consider the objects as as utility classes
for the interface and make sure we serialize them in the same way
regardless of platform and language.
I would appreciate any comments on
these issues whether people agree or disagree. I'll amend the document
next week and re-post it to hyades-dev for discussion on the Choreography
group call and the HCE group call.
