Re: [COAS-List] Proposed ObservationData IDL

[Tim Brinson <TBrinson@mindspring.com>]

> >     struct SiameseObservationData {
> >         QualifiedCodeStr code;
> >         sequence<SiameseObservationData> composite;
> >         sequence<SiameseObservationData> qualifiers;
> >         sequence<any,1> value;
> >     };
>
> This latter suggestion would preserve the structure in the existing
> ObservationData (but with
> an obvious need for an improved name :-).
> The same might apply to your SimpleObservationData examples.

Very good points.  Of course I was just being humourous with the Siamese thing.

> >Has anyone done a comparison?  In one case you are describing the
> >structure with
> >a TypeCode and the other you are describing the structure using
> >SiameseObservationData.  I can find examples where one is more efficient than
> >the other and vice versa.
>
> Chuck Carman has made the comment that in visibroker the expense of
> unmarshalling an Any
> was very large.  We've seen no obvious penalty from it or from Structs.

As I understood from the grapevine Visibroker had a real problem with Anys early
on.  I don't know if they fixed it or not.  The issue came up between all the
submitters to the IDL->Java mapping since they have the portable stubs.  This
caused the vendors to agree to interoperability at a much deeper level within the
ORB then before.  As you can imagine there was a bit of contingeny since each ORB
vendor wanted to make sure they didn't have to change their ORB.  In the end some
of the lesser known ORB vendors showed some of the others how it can be done
efficiently.

Tim