[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [hyades-dev] Choreography HCE Requirements

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.




-----Original Message-----
From: hyades-dev-admin@xxxxxxxxxxx [mailto:hyades-dev-admin@xxxxxxxxxxx] On Behalf Of Antony Miguel
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).


- 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


        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.




Antony Miguel
Scapa Technologies
+44 131 550 1766