Issue 1525: Type code marshalling (interop) Source: (, ) Nature: Revision Severity: Summary: Summary: If a type code does not have a repository ID (e.g. dynamic type ) then the member names for structs and unions etc. should be required to be sent on the wire for GIOP marsalling of Typecodes. This may help the type code comparision issue to be resolved. Resolution: Revised Text: Actions taken: June 14, 1998: received issue February 17, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Sun, 14 Jun 1998 13:01:11 -0400 From: ter@holta.ho.lucent.com (T E Rutt) To: interop@omg.org Subject: new interop issue on type code marshalling I want to add the following interop issue. If a type code does not have a repository ID (e.g. dynamic type ) then the member names for structs and unions etc. should be required to be sent on the wire for GIOP marsalling of Typecodes. This may help the type code comparision issue to be resolved. Tom Rutt Return-Path: Date: Mon, 15 Jun 1998 12:52:51 -0600 From: Javier Lopez-Martin To: interop@omg.org, ter@holta.ho.lucent.com Subject: Re: new interop issue on type code marshalling Content-Md5: RsPnUGXDpGNfw/4/3FEtDQ== > I want to add the following interop issue. > > > If a type code does not have a repository ID > > (e.g. dynamic type ) then the member names for > structs and unions etc. should be required to be > sent on the wire for GIOP marsalling of Typecodes. > > > > This may help the type code comparision issue to be resolved. I think this is a bad idea. Names cannot be compared safely, as they MUST be considered local to a certain ORB/IR instance. There is a high chance that these names are the same accross multiple ORBs/IRs, but this is NOT guarranteed or even suggested from the current CORBA specs. On the contrary, it is clearly specified that no such assumption should be made. So, in my opinion, names should NEVER be considered for comparison purposes, regardless of whether repository ids are present or absent from a typecode (with the exception of the equal() operation, that is pretty useless in my opinion, but should not be changed from its current semantics). Now, the other issue that is kind of hidden in you description is the status of repository ids. I think that the agreement from the previous RTF discussion was to make repository ids absolutely positively mandatory everywhere, with the only exception of being able to interoperate with other ORBs that might not have been upgraded to fulfill this requirement (therefore, typecodes coming from an older ORB might not have a repository id specified). However, in looking at the resolution text for this issue, it is too much ambiguity in the wording as to infer what I just said. I think we should state this explicitly, and require repository ids to be mandatory everywhere. The text should be more explicit to this respect. The only doubt that I have is whether repository ids should be mandatory also in the typecode creation operations exported by the ORB pseudo object. I can be convinced either way (make them mandatory or not) with sufficient argument. Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: Date: Tue, 16 Jun 1998 00:37:19 -0600 From: Javier Lopez-Martin To: interop@omg.org, ter@holta.ho.lucent.com, javier@cnd.hp.com Subject: Re: new interop issue on type code marshalling Content-Md5: x1vwt7PujBArC1MgIF813Q== Hello everyone, Following a private conversation on the topic with Tom Rutt, we think that further clarification of what the CORBA 2.2 spec says about this topic is in order, so that other people have a chance to state an opinion. Therefore, I am commenting on my previous post, providing further information. > > I want to add the following interop issue. > > > > > > If a type code does not have a repository ID > > > > (e.g. dynamic type ) then the member names for > > structs and unions etc. should be required to be > > sent on the wire for GIOP marsalling of Typecodes. > > > > > > > > This may help the type code comparision issue to be resolved. > > I think this is a bad idea. > > Names cannot be compared safely, as they MUST be considered local to > a certain ORB/IR instance. There is a high chance that these names > are the same accross multiple ORBs/IRs, but this is NOT guarranteed > or even suggested from the current CORBA specs. On the contrary, it > is > clearly specified that no such assumption should be made. In this paragraph, I am referring explicitly to the names of types and members of types. The names of operations within an interface are indeed significant, but not the names of types. Here is a quote from the CORBA 2.2 spec (page 8-38, section on Typecodes in the IR chapter): " The name operation can also be invoked on object reference, structure, union, enumeration, alias, and exception TypeCodes. It returns the simple name identifying the type within its enclosing scope. Since names are local to a Repository, the name returned from a TypeCode may not match the name of the type in any particular Repository, and may even be an empty string. The member_count and member_name operations can be invoked on structure, union, and enumeration TypeCodes. Member_count returns the number of members constituting the type. Member_name returns the simple name of the member identified by index. Since names are local to a Repository, the name returned from a TypeCode may not match the name of the member in any particular Repository, and may even be an empty string. " That is why I said: > So, in my opinion, names should NEVER be considered for comparison > purposes, regardless of whether repository ids are present or absent > from a typecode (with the exception of the equal() operation, that > is > pretty useless in my opinion, but should not be changed from its > current > semantics). > > Now, the other issue that is kind of hidden in you description is > the > status of repository ids. I think that the agreement from the > previous > RTF discussion was to make repository ids absolutely positively > mandatory > everywhere, with the only exception of being able to interoperate > with > other ORBs that might not have been upgraded to fulfill this > requirement > (therefore, typecodes coming from an older ORB might not have a > repository > id specified). > > However, in looking at the resolution text for this issue, it is too > much ambiguity in the wording as to infer what I just said. I think > we > should state this explicitly, and require repository ids to be > mandatory > everywhere. The text should be more explicit to this respect. > > The only doubt that I have is whether repository ids should be > mandatory > also in the typecode creation operations exported by the ORB pseudo > object. > I can be convinced either way (make them mandatory or not) with > sufficient > argument. > > Javier Lopez-Martin > Hewlett-Packard Co > javier@cnd.hp.com One more thing: this is the reason why I believe that the decission of the Minimum CORBA submitters to take out the id() operation from the TypeCode interface, but leave the name(), is completely wrong, and should be reversed. This same opinion has already been expressed by several other people in this forum, most likely for the same (or related) reasons. I would highly encourage Minimum CORBA submitters to reverse their current decission. As I don't know what is the mailing list that they use, I am not copying them; but any kind soul that has their email alias, please either forward this to them, or tell me so that I can forward it. Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com