Issue 1623: TypeCode comparison proposal (02) (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: 10. Define two new operations on TypeCodes: pseudo interface TypeCode { ... TypeCode get_compact_typecode(); TypeCode get_canonical_typecode(); ... }; TypeCode::get_compact_typecode() strips out all optional name & member name fields. TypeCode::get_canonical_typecode() looks up the TypeCode in the Interface Repository and returns the fully fleshed-out TypeCode. If the top level TypeCode does not contain a RepositoryId, (such as array and sequence TypeCodes, or TypeCodes from older ORBs), then a new TypeCode is constructed by calling TypeCode::get_canonical_typecode() on each member TypeCode of the original TypeCode. If the Interface Repository is unavailable, or does not contain the information needed, the call raises the INTF_REPOS system exception. Resolution: Revised Text: Actions taken: July 1, 1998: received issue July 1, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Date: Tue, 30 Jun 1998 20:00:37 -0400 From: Jonathan Biggar Organization: Floorboard Software To: orb_revision@omg.org Subject: New TypeCode comparison proposal I have rethought my proposal on TypeCode comparison, and I have decided to drop the idea of defining two different aliases of a TypeCode as being not equivalent in favor of the simpler solution that aliases are not considered significant at all for TypeCode comparison. Hopefully this will make it easier to reach a consensus. Instead, I will concentrate on making sure that the language mappings contain enough mechanism so that applications which need a stronger TypeCode comparison test can do so. Points 1 through 9 need to be considered as one unit. Point 10 can be voted on independently, but does provide a useful capability for controlling the size and content of TypeCodes. 10. Define two new operations on TypeCodes: pseudo interface TypeCode { ... TypeCode get_compact_typecode(); TypeCode get_canonical_typecode(); ... }; TypeCode::get_compact_typecode() strips out all optional name & member name fields. TypeCode::get_canonical_typecode() looks up the TypeCode in the Interface Repository and returns the fully fleshed-out TypeCode. If the top level TypeCode does not contain a RepositoryId, (such as array and sequence TypeCodes, or TypeCodes from older ORBs), then a new TypeCode is constructed by calling TypeCode::get_canonical_typecode() on each member TypeCode of the original TypeCode. If the Interface Repository is unavailable, or does not contain the information needed, the call raises the INTF_REPOS system exception. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 1 Jul 1998 11:02:02 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org Subject: Re: New TypeCode comparison proposal On Tue, 30 Jun 1998, Jonathan Biggar wrote: > I have rethought my proposal on TypeCode comparison, and I have > decided > to drop the idea of defining two different aliases of a TypeCode as > being not equivalent in favor of the simpler solution that aliases > are > not considered significant at all for TypeCode comparison. > Hopefully > this will make it easier to reach a consensus. Instead, I will > concentrate on making sure that the language mappings contain enough > mechanism so that applications which need a stronger TypeCode > comparison > test can do so. > > Points 1 through 9 need to be considered as one unit. Point 10 can > be > voted on independently, but does provide a useful capability for > controlling the size and content of TypeCodes. I like this proposal. In particular, I agree with the idea that preserving aliases is a language mapping issue. I'm not sure that point 10 is really necessary, but I don't have any objections either. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html > 10. Define two new operations on TypeCodes: > > pseudo interface TypeCode { > ... > TypeCode get_compact_typecode(); > TypeCode get_canonical_typecode(); > ... > }; > > TypeCode::get_compact_typecode() strips out all optional name & > member > name fields. TypeCode::get_canonical_typecode() looks up the > TypeCode > in the Interface Repository and returns the fully fleshed-out > TypeCode. > If the top level TypeCode does not contain a RepositoryId, (such as > array and sequence TypeCodes, or TypeCodes from older ORBs), then a > new > TypeCode is constructed by calling > TypeCode::get_canonical_typecode() on > each member TypeCode of the original TypeCode. If the Interface > Repository is unavailable, or does not contain the information > needed, > the call raises the INTF_REPOS system exception. You are assuming that the only way to obtain the full TypeCode back is from the IR. While this is certainly a likely situation, some ORBs might choose to use other internal mechanisms to regain such information, without the need of an IFR. We should not preclude such implementations. Return-Path: Date: Tue, 30 Jun 1998 19:23:46 -0600 From: Javier Lopez-Martin To: orb_revision@omg.org, jon@floorboard.com Subject: Re: New TypeCode comparison proposal Content-Md5: NU375ldgImdwHrls+5BQDg== Hi Jon, I'm glad to see this back on the table, as I think it is really important. Some minor comments are inline: > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Hope this helps. I will send, in a separate email, a complement to this regarding the "yet more compact" encoding proposal that I sent some days ago, aligning it with this one. I'm sendind it in a separate email because it is a separate issue, and can be treated independently. Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: Date: Tue, 30 Jun 1998 22:37:24 -0400 From: Bob Kukura Organization: IONA Technologies To: Jonathan Biggar CC: orb_revision@omg.org Subject: Re: New TypeCode comparison proposal References: <35997C25.CEA88C19@floorboard.com> I believe the proposed form of TypeCode comparison is useful, and therefore I support most of this proposal. This does not mean that other forms of TypeCode comparison might not also be useful. I oppose point 9 because I believe that comparing whether all operations will return the same result may also be useful in some cases, and therefore equal() should not be deprecated or even banished from internal use. Finally, I am leaning towards opposing point 10. The proposed get_canonical_typecode() operation would take a significant amount of code to implement and signficant time to execute. This functionality would better be provided via an operation on CORBA::Repository. This would not bloat the ORB core as much, and far fewer remote calls would be needed to canonize a TypeCode. Also, there would be a well-defined source for the names. -Bob Jonathan Biggar wrote: Return-Path: Date: Tue, 30 Jun 1998 20:57:27 -0600 From: Javier Lopez-Martin To: orb_revision@omg.org, jon@floorboard.com, javier@cnd.hp.com Subject: Re: New TypeCode comparison proposal Content-Md5: QDvT6kt3hltGydNazL3cDA== A couple more comments I forgot in my prior email: > > 10. Define two new operations on TypeCodes: > > > > pseudo interface TypeCode { > > ... > > TypeCode get_compact_typecode(); > > TypeCode get_canonical_typecode(); > > ... > > }; > > > > TypeCode::get_compact_typecode() strips out all optional name & > member > > name fields. TypeCode::get_canonical_typecode() looks up the > TypeCode > > in the Interface Repository and returns the fully fleshed-out > TypeCode. > > If the top level TypeCode does not contain a RepositoryId, (such > as > > array and sequence TypeCodes, or TypeCodes from older ORBs), then > a new > > TypeCode is constructed by calling > TypeCode::get_canonical_typecode() on > > each member TypeCode of the original TypeCode. If the Interface > > Repository is unavailable, or does not contain the information > needed, > > the call raises the INTF_REPOS system exception. No mention is made of what happens to aliases in the typecodes when applying these operations. I would suggest that text would be added so that they remain intact with these operations (no aliases are stripped or introduced by these operations). Another global issue: if this is going to CORBA 2.3 (as I hope it does!), then the new typecodes introduced by OBV should be taken into consideration, and added to this discussion in the relevant places. Javier Lopez-Martin Hewlett-Packard Co javier@cnd.hp.com Return-Path: Date: Tue, 30 Jun 1998 23:26:23 -0400 From: Jonathan Biggar Organization: Floorboard Software To: Bob Kukura CC: orb_revision@omg.org Subject: Re: New TypeCode comparison proposal References: <35997C25.CEA88C19@floorboard.com> <3599A0E4.E35FC7C4@iona.com> Bob Kukura wrote: > Finally, I am leaning towards opposing point 10. The proposed > get_canonical_typecode() operation would take a significant amount > of > code to implement and signficant time to execute. This > functionality > would better be provided via an operation on CORBA::Repository. > This > would not bloat the ORB core as much, and far fewer remote calls > would > be needed to canonize a TypeCode. Also, there would be a > well-defined > source for the names. This is a pretty good suggestion. If others think this is reasonable, then we could leave the get_compact_typecode() operation on TypeCode, and move the get_canonical_typecode() to CORBA::Repository as: TypeCode get_canonical_typecode(in TypeCode tc); -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Tue, 30 Jun 1998 23:36:31 -0400 From: Jonathan Biggar Organization: Floorboard Software To: Javier Lopez-Martin CC: orb_revision@omg.org Subject: Re: New TypeCode comparison proposal References: <199807010123.AA151126226@ovdm40.cnd.hp.com> Javier Lopez-Martin wrote: > > > 10. Define two new operations on TypeCodes: > > > > pseudo interface TypeCode { > > ... > > TypeCode get_compact_typecode(); > > TypeCode get_canonical_typecode(); > > ... > > }; > > > > TypeCode::get_compact_typecode() strips out all optional name & member > > name fields. TypeCode::get_canonical_typecode() looks up the TypeCode > > in the Interface Repository and returns the fully fleshed-out TypeCode. > > If the top level TypeCode does not contain a RepositoryId, (such as > > array and sequence TypeCodes, or TypeCodes from older ORBs), then a new > > TypeCode is constructed by calling TypeCode::get_canonical_typecode() on > > each member TypeCode of the original TypeCode. If the Interface > > Repository is unavailable, or does not contain the information needed, > > the call raises the INTF_REPOS system exception. > > You are assuming that the only way to obtain the full TypeCode back is > from the IR. While this is certainly a likely situation, some ORBs might > choose to use other internal mechanisms to regain such information, > without the need of an IFR. We should not preclude such implementations. Ok, change it to say that it looks it up from the IR or other ORB implementation specific method, as long as that method would return the same result. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Tue, 30 Jun 1998 23:37:46 -0400 From: Jonathan Biggar Organization: Floorboard Software To: Javier Lopez-Martin CC: orb_revision@omg.org Subject: Re: New TypeCode comparison proposal References: <199807010257.AA155881846@ovdm40.cnd.hp.com> Javier Lopez-Martin wrote: > A couple more comments I forgot in my prior email: > > > > 10. Define two new operations on TypeCodes: > > > > > > pseudo interface TypeCode { > > > ... > > > TypeCode get_compact_typecode(); > > > TypeCode get_canonical_typecode(); > > > ... > > > }; > > > > > > TypeCode::get_compact_typecode() strips out all optional name & member > > > name fields. TypeCode::get_canonical_typecode() looks up the TypeCode > > > in the Interface Repository and returns the fully fleshed-out TypeCode. > > > If the top level TypeCode does not contain a RepositoryId, (such as > > > array and sequence TypeCodes, or TypeCodes from older ORBs), then a new > > > TypeCode is constructed by calling TypeCode::get_canonical_typecode() on > > > each member TypeCode of the original TypeCode. If the Interface > > > Repository is unavailable, or does not contain the information needed, > > > the call raises the INTF_REPOS system exception. > > No mention is made of what happens to aliases in the typecodes when > applying these operations. I would suggest that text would be added so > that they remain intact with these operations (no aliases are stripped > or introduced by these operations). I had assumed that by only stating that the name & member_name fields were affected, that alias TypeCodes would remain intact. If you think we need to say so explicity, that's ok. > Another global issue: if this is going to CORBA 2.3 (as I hope it does!), > then the new typecodes introduced by OBV should be taken into consideration, > and added to this discussion in the relevant places. True.-- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org