Re: [hyades-dev] Variable group discovery, streaming generally

[Allan K Pratt <apratt@xxxxxxxxxx>]

I am not in favor of queries that force a client to do progressive 
discovery of variable groups. I think any client that wants to know about 
variable groups will want to know everything all at once, so it can build 
its UI. Having a multitude of little query calls will mean unnecessary 
traffic and turnaround on the wire.

Let's say that each group has an id, a name, a description, zero or more 
variables in the group, and zero or more subgroups. A single 
GetVariableGroupInfo call can return a data structure that represents all 
that, all at once.

Since variable and group ids are strings, the reply is a combination of 
strings and integers. A single node has this structure:

        String: id of this group
        String: name of this group
        String: description of this group
        Integer: number of variables in this group
        Integer: number of subgroups in this group
        String[] id for each variable in this group

This is a recursive data structure: what follows in another block just 
like this, giving the group id, name, etc. for the first subgroup of this 
group. If this subgroup has subgroups of its own, they'll follow 
immediately (depth first). When you exhaust the subgroups, the next node 
is the second subgroup of the root group.

Example, where G represents a single instance of the structure above:

        G1 has subgroups = 2
                G2 is the first subgroup of G1; has subgroups = 1
                        G3 is the first subgroup of G2; has subgroups = 0
                G4 is the second subgroup of G1, has subgroups = 0

This would serialize as G1 G2 G3 G4.

Regarding the stream format for serializing data and structures: rather 
than inventing yet another object serialization format, maybe we should 
really be using the Java one. This makes our work Java-centric, with extra 
work required for non-Java clients and agents, but at least it's a defined 
format and it'll be convenient for SOMEBODY, instead of an invented format 
which might have mistakes and which will be convenient for NOBODY.

-- Allan Pratt, apratt@xxxxxxxxxx
Rational software division of IBM




"Antony Miguel" <antony.miguel@xxxxxxxxxxxxx> 
Sent by: hyades-dev-admin@xxxxxxxxxxx
08/20/2004 09:26 AM
Please respond to
hyades-dev


To
<hyades-dev@xxxxxxxxxxx>
cc

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
        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
 
Antony Miguel
Scapa Technologies
antony.miguel@xxxxxxxxxxxxx
+44 131 550 1766