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 they’d end up being
converted to ID’s somewhere, possibly at both ends. I’m 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.