[omniORB] DynAny and typecode aliases

[Stephen Crawley]

> On Tuesday 12 October, Stephen Crawley wrote:
> 
> >   CORBA::TypeCode_ptr tc = // ... typecode for "typedef long Int;"
> > 
> >   CORBA::DynAny_ptr da = orb -> create_dyn_basic_type(tc);
> > 
> >   cerr << "kind is " << kind_to_string(da -> type() -> kind()) << endl;
> > 
> > is printing "kind is long", not "kind is alias".
> > 
> > The problem is that CORBA::ORB::create_basic_dyn_any() is stripping
> > off the aliasing and creating the DynAnyImpl object with the stripped
> > typecode.  This violates the intent of the CORBA 2.2 spec.
> 
> I wasn't involved in omniORB's DynAny implementation, but I've just
> read the 2.2 spec. It does not specify how the TypeCodes should be
> assigned at all, except the paragraph
> 
>   "The create_dyn_any operations creates a new DynAny object from an
>    any value. A duplicate of the TypeCode associated with the any
>    value is assigned to the resulting DynAny object. ..."
> 
> No specific behaviour is given for the creation functions which take
> TypeCode arguments.
> 
> It could be argued, as you do, that the TypeCodes should be duplicated
> without change. 

To me this is the obvious, natural reading of 2.2 spec.  It is also the one
that gives semantics for DynAny that are consistent with its purpose; i.e.
portable creation and examination of >>all<< kinds of Any values.  

> However, it can also be argued that without a notion
> of TypeCode equivalence (which was introduced with 2.3), it is more
> useful to strip any aliases (i.e. compact the TypeCodes in 2.3
> terminology) so that typecodes of structurally equivalent types
> compare equal.

I believe that this interpretation is inconsistent with the rest of
the CORBA 2.2 spec, and other parts of the omniORB implementation:
  
  1)  As I've already said, it makes it impossible to use DynAny
      to create Any values whose TypeCodes are aliases.  Nobody
      can argue that these values are not legal.

  2)  The CORBA 2.* semantics for duplicating TypeCodes do 
      not include stripping off aliases.  If this behaviour was
      intended, it would be explicitly stated. 

  3)  The omniORB implementation of TypeCode::_duplicate() doesn't 
      strip aliases.  In other words, the omniORB implementation
      interprets "duplicate a TypeCode" to mean different things
      for TypeCode::_duplicate and the create_dyn_any operations.

Furthermore, there are other CORBA specifications (e.g. MOF and XMI)
that rely on ORBs not screwing around with TypeCodes.

> This is something which needs to be clarified in the spec, since it is
> not at all obvious to my reading. Unfortunately, the 2.3 spec still
> doesn't make it explicit. It seems odd to me that both specs are very
> clear about the behaviour when generating a DynAny from an Any, but
> not at all clear about generation with a TypeCode. Since issues of
> TypeCode equivalence have now been clarified, however, a better
> argument can be made for keeping alises in the TypeCodes.

I agree that it would be a good idea to clarify the DynAny spec further in the
current RTF cycle.  I'll lodge an RTF issue, and hopefully the work can be done
in the current cycle.

However, that doesn't help with the problem in hand; i.e. fixing the DynAny
implementation in omniORB 2.8 / 3.0.  Who on the omniORB team can I talk to
about getting this fixed?  I've offered to help, but I need:

  1)  someone to tell me where the DynAny test harness lives, and

  2)  someone to discuss the impact of changing DynAny behaviour on
      the rest of the omniORB code base.

-- Steve