Issue 666: Native types with respect to typecodes, DII, DSI,Interface Reposit. (orb_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: The portability spec is silent on issue of native types with respect to typecodes, DII, DSI and Interface Repository. Issue should be addressed. (see archive for details) Resolution: Proposed resolution is to add representation of native type in the IR. Details below as proposed by Revised Text: Here are the proposed extensions to allow native types in the IR. Our Actions taken: August 11, 1997: received issue May 12, 1998: issue moved from port-rtf to orb_revision February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jon@sems.com Date: Mon, 11 Aug 1997 14:59:38 -0700 From: Jonathan Biggar Organization: Seagate Software, Network & Storage Management Group To: port-rtf@omg.org, issues@omg.org Subject: Not the last Portability issue... The Portability spec is silent on the issue of native types with respect to typecodes, DII and DSI, and the Interface Repository. It should address this issue in one of two ways: 1. State that any interface which uses a native type as an argument or return value will not be represented in the Interface Repository, and cannot be used with the DII or DSI. or 2. Define a typecode to represent native types so that interfaces that use a native type can be entered into the Interface Repository. Language mappings would also need to be modified to discuss how to use a native typecode in the DII or DSI. Of course, the restriction that native types cannot be marshalled still applies. Jon Biggar jon@sems.com Return-Path: Sender: jon@floorboard.com Date: Sat, 11 Apr 1998 20:51:38 -0700 From: Jonathan Biggar To: port-rtf@omg.org Subject: Re: Issue 666 proposal Proposal: 1. Add the following text to section 3.8 "Native Types" after the paragraph that ends with "Any attempt to transmit a value of a native type in a remote invocation may raise the MARSHAL standard exception.": Since the native type cannot be represented in the Interface Repository, IDL modules which contain a nested native type declaration will not appear in the Interface Repository. It is recommended that developers keep this restriction in mind when writing IDL specifications. Discussion: Since nearly everyone gagged at the idea of adding interfaces to the IR that described native types (and even more at the idea of actually supporting a native type using the DII or DSI), the only clean way to keep the "natives" out of the IR is to forbid any module that contains a native type from appearing in the IR. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Tue, 21 Apr 1998 11:03:26 -0400 From: Bob Kukura Organization: IONA Technologies To: Jonathan Biggar CC: port-rtf@omg.org Subject: Re: Issue 666 proposal References: <35303A4A.8ED0621D@floorboard.com> Recent email regarding tk_native seems to indicate a consensus forming around the need to represent native in TypeCodes at least. I'm convinced the same needs to be done in the IFR, and I really don't think it is at all difficult. I don't like the implications of not being able to represent certain modules in an IFR. If native were ever to be used in the CORBA module (which might be useful if we ever do try to eliminate existing use of pseudo-IDL), then dependencies in other IDL on types defined in the CORBA module (such as RepositoryId) would be broken. -Bob Jonathan Biggar wrote: > > Proposal: > > 1. Add the following text to section 3.8 "Native Types" after the > paragraph that ends with "Any attempt to transmit a value of a > native > type in a remote invocation may raise the MARSHAL standard > exception.": > > Since the native type cannot be represented in the Interface > Repository, > IDL modules which contain a nested native type declaration will not > appear in the Interface Repository. It is recommended that > developers > keep this restriction in mind when writing IDL specifications. > > Discussion: > > Since nearly everyone gagged at the idea of adding interfaces to the > IR > that described native types (and even more at the idea of actually > supporting a native type using the DII or DSI), the only clean way > to > keep the "natives" out of the IR is to forbid any module that > contains a > native type from appearing in the IR. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Return-Path: Sender: jon@floorboard.com Date: Tue, 21 Apr 1998 08:30:11 -0700 From: Jonathan Biggar To: Bob Kukura CC: port-rtf@omg.org Subject: Re: Issue 666 proposal References: <35303A4A.8ED0621D@floorboard.com> <353CB53E.AB19F8CB@iona.com> Bob Kukura wrote: > > Recent email regarding tk_native seems to indicate a consensus > forming > around the need to represent native in TypeCodes at least. I'm > convinced the same needs to be done in the IFR, and I really don't > think > it is at all difficult. I don't like the implications of not being > able > to represent certain modules in an IFR. If native were ever to be > used > in the CORBA module (which might be useful if we ever do try to > eliminate existing use of pseudo-IDL), then dependencies in other > IDL on > types defined in the CORBA module (such as RepositoryId) would be > broken. In spite of my previous proposal, I agree with you on this one now. Since the new Java spec opened the door by adding support in TypeCodes, it appears we need to go further and specify native support in the IR. The only question left is whether native support is necessary in the any type, and by extension in the DII and DSI. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Sender: gscott@corp.inprise.com Date: Tue, 12 May 1998 18:30:00 -0700 From: "George M. Scott" Organization: Borland International, Inc. To: port-rtf@omg.org CC: Jonathan Biggar , Bob Kukura Subject: Re: Issue 666 proposal References: <35303A4A.8ED0621D@floorboard.com> <353CB53E.AB19F8CB@iona.com> <353CBB83.F8B71264@floorboard.com> Jonathan Biggar wrote: > Bob Kukura wrote: > > > > Recent email regarding tk_native seems to indicate a consensus > forming > > around the need to represent native in TypeCodes at least. I'm > > convinced the same needs to be done in the IFR, and I really don't > think > > it is at all difficult. I don't like the implications of not > being able > > to represent certain modules in an IFR. If native were ever to be > used > > in the CORBA module (which might be useful if we ever do try to > > eliminate existing use of pseudo-IDL), then dependencies in other > IDL on > > types defined in the CORBA module (such as RepositoryId) would be > > broken. > > In spite of my previous proposal, I agree with you on this one now. > Since > the new Java spec opened the door by adding support in TypeCodes, it > appears we need to go further and specify native support in the IR. > The > only question left is whether native support is necessary in the any > type, and by extension in the DII and DSI. Here are our proposed extensions to allow native types in the IR. Our currentposition on DII/DSI with native types is that it should not be allowed. The proposed IR changes are as follows: A new definition kind is added called dk_Native: enum DefinitionKind { dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Sequence, dk_Array, dk_Repository, dk_Wstring, dk_Fixed, // OBV dks go here dk_Native // value = 23 accomodating OBV changes }; A new create operation is added, called create_native: module CORBA { ... interface NativeDef; interface Container: IRObject { .... NativeDef create_native( in RepositoryId id, in Identifier name, in VersionSpec version ); ... }; ... }; A new interface called NativeDef is also added, which defines no additional operations. module CORBA { ... interface NativeDef: TypedefDef { }; ... }; These changes should be straightforward and easily implementable by ORB vendors. George Return-Path: Sender: jon@floorboard.com Date: Tue, 12 May 1998 22:45:47 -0700 From: Jonathan Biggar To: "George M. Scott" CC: port-rtf@omg.org, Bob Kukura Subject: Re: Issue 666 proposal References: <35303A4A.8ED0621D@floorboard.com> <353CB53E.AB19F8CB@iona.com> <353CBB83.F8B71264@floorboard.com> <3558F798.81D681D6@corp.inprise.com> This looks fine, you have my vote. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org George M. Scott wrote: > Here are our proposed extensions to allow native types in the IR. Our currentposition on DII/DSI with native types is > that it should not be allowed. > > The proposed IR changes are as follows: > > A new definition kind is added called dk_Native: > > enum DefinitionKind { > dk_none, dk_all, > dk_Attribute, dk_Constant, dk_Exception, dk_Interface, > dk_Module, dk_Operation, dk_Typedef, > dk_Alias, dk_Struct, dk_Union, dk_Enum, > dk_Primitive, dk_String, dk_Sequence, dk_Array, > dk_Repository, dk_Wstring, dk_Fixed, > // OBV dks go here > dk_Native // value = 23 accomodating OBV changes > }; > > A new create operation is added, called create_native: > > module CORBA { > ... > interface NativeDef; > interface Container: IRObject { > .... > > NativeDef create_native( > in RepositoryId id, > in Identifier name, > in VersionSpec version > ); > ... > }; > ... > }; > > A new interface called NativeDef is also added, which defines > no additional operations. > > module CORBA { > ... > > interface NativeDef: TypedefDef { > }; > ... > }; Return-Path: Sender: jis@fpk.hp.com Date: Wed, 24 Jun 1998 15:48:18 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard New Jersey Labs To: orb_revision@omg.org Subject: Proposal for Issues 666 an 992 Please see attached. Jishnu. -- Jishnu Mukerji Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Issue 666: Native types with respect to typecodes, DII, DSI,Interface Reposit. (orb_revision) Click here for this issue's archive. Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) Nature: Uncategorized Severity: Summary: The portability spec is silent on issue of native types with respect to typecodes, DII, DSI and Interface Repository. Issue should be addressed. (see archive for details) Resolution: Proposed resolution is to add representation of native type in the IR. Details below as proposed by George Scott. Here are the proposed extensions to allow native types in the IR. Our current position on DII/DSI with native types is that it should not be allowed. The proposed IR changes are as follows: A new definition kind is added called dk_Native: enum DefinitionKind { dk_none, dk_all, dk_Attribute, dk_Constant, dk_Exception, dk_Interface, dk_Module, dk_Operation, dk_Typedef, dk_Alias, dk_Struct, dk_Union, dk_Enum, dk_Primitive, dk_String, dk_Sequence, dk_Array, dk_Repository, dk_Wstring, dk_Fixed, // OBV dks go here dk_Native // value = 23 accomodating OBV changes }; A new create operation is added, called create_native: module CORBA { ... interface NativeDef; interface Container: IRObject { .... NativeDef create_native( in RepositoryId id, in Identifier name, in VersionSpec version ); ... }; ... }; A new interface called NativeDef is also added, which defines no additional operations. module CORBA { ... interface NativeDef: TypedefDef { }; ... }; These changes should be straightforward and easily implementable by ORB vendors. George Revised Text: Actions taken: August 11, 1997: received issue May 12, 1998: issue moved from port-rtf to orb_revision Return-Path: From: Jeffrey Mischkinsky Subject: Re: IONA votes and comments To: jon@floorboard.com (Jonathan Biggar) Date: Fri, 17 Jul 1998 17:32:22 -0700 (PDT) Cc: jis@fpk.hp.com, kukura@iona.com, orb_revision@omg.org 'Jonathan Biggar' writes: > > Jishnu Mukerji wrote: > > > > Bob Kukura wrote: > > > > > Vote 2: > > > ------- > > > > > > I guess its too late to vote, but I think issue 666 needs to be > > > reopened. The adopted resolution adds IFR support for native, > but > > > doesn't add TypeCode support, which is required for the type() > attribute > > > inherited by NativeDef to work. I think tk_native should behave > and > > > marshal similarly to tk_objref. > > > > Egads! Jeff gave me a version of Chapter 8 which contained the > definition > > of tk_native, but not the dk_native stuff, and he told me that the > > tk_native stuff was adopted as part of some Portability RTF or the > other. > > The proposed resolution that was there in the archive from George > Scott > > contained only the dk_native stuff so I figured that the tk_native > stuff > > may actually have been included in some Portability RTF and that > is why it > > was not there. Just in case that is not the case, I will put > together the > > tk_native related changes in an add-on proposal and publish it > over email, > > and we can discuss it at the teleconference on Thursday. > > You have jogged my memory. I think it was the IDL to Java or Java > to > IDL RTF, probably the latter. Java/POA submission - which is where i got the stuff for Jishnu. I do seem to recall some discussion that it wasn't "completely complete". There was also a small amount of controversy. I think the Java/POA did just enough to support what we thought we needed for the Java Language mapping (or at least the part that we thought about.) jeff > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-312-5158 jeffm@visigenic.com +1 650-312-5158