| [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).
- Variable grouping
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
e.g.
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
e.g.
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.
cheers
|