| Re: [hyades-dev] Variable group discovery, streaming generally |
Here's the latest update of the Choreography HCE requirements document. I agree that using methods to poll for a structure is a bad idea, so I've added classes to represent variables and variable groups. cheers Antony Miguel Scapa Technologies antony.miguel@xxxxxxxxxxxxx +44 131 550 1766 ----- Original Message ----- From: "Allan K Pratt" <apratt@xxxxxxxxxx> To: <hyades-dev@xxxxxxxxxxx> Sent: Friday, August 20, 2004 7:56 PM Subject: Re: [hyades-dev] Variable group discovery, streaming generally > 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 > > _______________________________________________ > hyades-dev mailing list > hyades-dev@xxxxxxxxxxx > http://dev.eclipse.org/mailman/listinfo/hyades-dev >
Attachment:
Choreography HCE Requirements.zip
Description: Zip compressed data