Issue 3177: local interfaces and the DII (orb_revision) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com) Nature: Uncategorized Issue Severity: Summary: The current spec for local interfaces disallows making calls to a local interface via the DII. It turns out that this is rather inconvenient for implementors of scripting languages. That's because, for a scripting language, *everything* is a DII request. Local interfaces, therefore, force the implementor to wrap all pseudo-objects and local interfaces in special wrapper objects. For pseudo-objects, there is nothing we can do. However, for local interfaces, we could require DII calls to be supported. Resolution: resolved, see above Revised Text: Actions taken: January 5, 2000: received issue January 5, 2000: moved from core rtf to components ftf May 19, 2001: moved from components ftf back to core May 13, 2002: closed issue Discussion: Since local interfaces are allowed to take native values for parameters, which you cannot pass via DII. So we'll have to limit DII usage on local inter- faces anyway (e.g. you could not call activate_object on the POA). End of Annotations:===== Date: Wed, 5 Jan 2000 12:00:32 +1000 (EST) From: Michi Henning To: Core Revision Task Force Subject: local interfaces and the DII Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: @7Qe9"0ad9G$l!!@1D!! The current spec for local interfaces disallows making calls to a local interface via the DII. It turns out that this is rather inconvenient for implementors of scripting languages. That's because, for a scripting language, *everything* is a DII request. Local interfaces, therefore, force the implementor to wrap all pseudo-objects and local interfaces in special wrapper objects. For pseudo-objects, there is nothing we can do. However, for local interfaces, we could require DII calls to be supported. Opinions? Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: jon@corvette.floorboard.com Message-ID: <3872B8C7.4F414FA@floorboard.com> Date: Tue, 04 Jan 2000 19:21:43 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Core Revision Task Force , components-ftf@omg.org Subject: Re: local interfaces and the DII References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: JH>e9B7ed9AdJe9$eb!! Michi Henning wrote: > > The current spec for local interfaces disallows making calls to a > local > interface via the DII. It turns out that this is rather inconvenient > for implementors of scripting languages. That's because, for a > scripting > language, *everything* is a DII request. Local interfaces, > therefore, force > the implementor to wrap all pseudo-objects and local interfaces in > special wrapper objects. > > For pseudo-objects, there is nothing we can do. However, for local > interfaces, we could require DII calls to be supported. > > Opinions? [This is still in the Component's bailiwick, since their FTF has not completed.] I argued for requiring DII to work for local objects at the time that they were added to the spec, but got outvoted. I hadn't thought of this argument, which I believe is pretty powerful. I've always believed that since the ORB must include operation demultiplexing and unmarshalling code to support object skeletons, making that code work as well for the DII for local objects (as well as plain old collocated objects) isn't difficult and doesn't add any appreciable overhead (size or runtime). -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 5 Jan 2000 09:35:26 -0330 From: Matthew Newhook To: Jonathan Biggar Cc: Michi Henning , Core Revision Task Force , components-ftf@omg.org Subject: Re: local interfaces and the DII Message-ID: <20000105093526.B20000@ooc.com> References: <3872B8C7.4F414FA@floorboard.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <3872B8C7.4F414FA@floorboard.com> Content-Type: text/plain; charset=us-ascii X-UIDL: aN"e9EP!!!e[Fe9hka!! Hi, On Tue, Jan 04, 2000 at 07:21:43PM -0800, Jonathan Biggar wrote: > I argued for requiring DII to work for local objects at the time > that > they were added to the spec, but got outvoted. I hadn't thought of > this > argument, which I believe is pretty powerful. > > I've always believed that since the ORB must include operation > demultiplexing and unmarshalling code to support object skeletons, > making that code work as well for the DII for local objects (as well > as > plain old collocated objects) isn't difficult and doesn't add any > appreciable overhead (size or runtime). It does add significant size overhead since at present it isn't necessary to include all the unmarshaling code in the local interface skeleton. > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Regards, Matthew -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 Sender: jis@fpk.hp.com Message-ID: <387363EC.A2FBCF37@fpk.hp.com> Date: Wed, 05 Jan 2000 10:31:56 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: Jonathan Biggar Cc: Michi Henning , Core Revision Task Force , components-ftf@omg.org Subject: Re: local interfaces and the DII References: <3872B8C7.4F414FA@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: &6gd9E**!!5AKe9!''!! Juergen, Please assign this one to Components FTF. Thanks, Jishnu. Jonathan Biggar wrote: > > Michi Henning wrote: > > > > The current spec for local interfaces disallows making calls to a > local > > interface via the DII. It turns out that this is rather > inconvenient > > for implementors of scripting languages. That's because, for a > scripting > > language, *everything* is a DII request. Local interfaces, > therefore, force > > the implementor to wrap all pseudo-objects and local interfaces in > > special wrapper objects. > > > > For pseudo-objects, there is nothing we can do. However, for local > > interfaces, we could require DII calls to be supported. > > > > Opinions? > > [This is still in the Component's bailiwick, since their FTF has not > completed.] > > I argued for requiring DII to work for local objects at the time > that > they were added to the spec, but got outvoted. I hadn't thought of > this > argument, which I believe is pretty powerful. > > I've always believed that since the ORB must include operation > demultiplexing and unmarshalling code to support object skeletons, > making that code work as well for the DII for local objects (as well > as > plain old collocated objects) isn't difficult and doesn't add any > appreciable overhead (size or runtime). > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: Paul Kyzivat To: "'Michi Henning'" , Core Revision Task Force Subject: RE: local interfaces and the DII Date: Wed, 5 Jan 2000 09:52:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: lc=!!_5A!!Y6P!!LZQd9 Personally, I would rather put the burden on the scripting language than impose it everywhere else. Couldn't you deal with this in the language binding for scripting languages? Paul > -----Original Message----- > From: Michi Henning [mailto:michi@ooc.com.au] > Sent: Tuesday, January 04, 2000 9:01 PM > To: Core Revision Task Force > Subject: local interfaces and the DII > > > The current spec for local interfaces disallows making calls > to a local > interface via the DII. It turns out that this is rather inconvenient > for implementors of scripting languages. That's because, for > a scripting > language, *everything* is a DII request. Local interfaces, > therefore, force > the implementor to wrap all pseudo-objects and local interfaces in > special wrapper objects. > > For pseudo-objects, there is nothing we can do. However, for local > interfaces, we could require DII calls to be supported. > > Opinions? > > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA > http://www.ooc.com.au/staff/michi-henning.html > Sender: jbiggar@corvette.floorboard.com Message-ID: <3873AC62.A7C4742A@floorboard.com> Date: Wed, 05 Jan 2000 12:41:06 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "'Michi Henning'" , Core Revision Task Force Subject: Re: local interfaces and the DII References: <9B164B713EE9D211B6DC0090273CEEA91402A2@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: lgjd97Dg!!446e98oS!! Paul Kyzivat wrote: > > Personally, I would rather put the burden on the scripting language > than > impose it everywhere else. > > Couldn't you deal with this in the language binding for scripting > languages? The issue isn't a problem with the language binding for scripting languages per se, but a problem when attempting to implement the language binding for a scripting language using a C++ ORB implementation, for example. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jbiggar@corvette.floorboard.com Message-ID: <3873AC2C.D65E2A93@floorboard.com> Date: Wed, 05 Jan 2000 12:40:12 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Newhook CC: Michi Henning , Core Revision Task Force , components-ftf@omg.org Subject: Re: local interfaces and the DII References: <3872B8C7.4F414FA@floorboard.com> <20000105093526.B20000@ooc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~A)e90c,e9]9$!!D#&e9 Matthew Newhook wrote: > > Hi, > > On Tue, Jan 04, 2000 at 07:21:43PM -0800, Jonathan Biggar wrote: > > I argued for requiring DII to work for local objects at the time > that > > they were added to the spec, but got outvoted. I hadn't thought > of this > > argument, which I believe is pretty powerful. > > > > I've always believed that since the ORB must include operation > > demultiplexing and unmarshalling code to support object skeletons, > > making that code work as well for the DII for local objects (as > well as > > plain old collocated objects) isn't difficult and doesn't add any > > appreciable overhead (size or runtime). > > It does add significant size overhead since at present it isn't > necessary > to include all the unmarshaling code in the local interface > skeleton. Yes, this is true. Two points however: 1. It certainly doesn't add any additional work for the IDL compiler, since it needs to generate code to handle this for normal colocated objects anyway. 2. Local interfaces are still allowed to be implemented as normal POA-mediated objects. Now we have some object references which support DII calls and some that don't and the two are indistinguishable. This isn't a good situation, in my book. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: Paul Kyzivat To: "'Jonathan Biggar'" , Paul Kyzivat Cc: "'Michi Henning'" , Core Revision Task Force Subject: RE: local interfaces and the DII Date: Wed, 5 Jan 2000 16:49:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: WXVd9cUed9~ZW!!O;*e9 > The issue isn't a problem with the language binding for scripting > languages per se, but a problem when attempting to implement the > language binding for a scripting language using a C++ ORB > implementation, for example. So, it is still a tradeoff. Do we require extra stuff in the c++ (and Java and ...) language bindings, or in the implementation of scripting language binding on top of a c++ (or java, ...) orb. Date: Mon, 08 Oct 2001 16:59:28 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard SSO Staff, Florham Park NJ, USA X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Proposed resolution for issue 3177 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: L]Ge9 Reply-To: Ken Cavanaugh Subject: Re: Proposed resolution for issue 3177 To: orb_revision@omg.org, jishnu_mukerji@hp.com, java-rtf@omg.org Cc: corba-dev@sun.com MIME-Version: 1.0 Content-MD5: u7XXmuU4gdE6UgajeSPEQQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: &Z!e9dWT!!+UMd96O/e9 Status: RO >X-Authentication-Warning: engmail1.Eng.Sun.COM: noaccess owned process doing -bs >X-Authentication-Warning: engmail1.Eng.Sun.COM: noaccess@localhost didn't use HELO protocol >From: Jishnu Mukerji >X-Accept-Language: en >MIME-Version: 1.0 >To: orb_revision@omg.org >Subject: Proposed resolution for issue 3177 >Content-Transfer-Encoding: 7bit > >This one is to check if everyone is awake, and if not then to provoke >them to wake up:-) Ok, I'm awake now :-). > >The following resolution will appear in the vote that will go out on >Friday 10/12 unless there is serious technical objection to it. > >Thanks, > >Jishnu. >_______________________________________________________________________ > >Issue 3177: local interfaces and the DII (orb_revision) > >Click here for this issue's archive. >Source: IONA (Mr. Michi Henning, michi.henning@iona.com) >Nature: Uncategorized Issue >Severity: >Summary: The current spec for local interfaces disallows making calls >to >a local >interface via the DII. It turns out that this is rather inconvenient >for implementors of scripting languages. That's because, for a >scripting >language, *everything* is a DII request. Local interfaces, therefore, >force >the implementor to wrap all pseudo-objects and local interfaces in >special wrapper objects. > >For pseudo-objects, there is nothing we can do. However, for local >interfaces, we could require DII calls to be supported. > >Resolution: >Since no one seems to have objected to the proposal to allow local >objects to be used >in DII, remove the restriction preventing such use from Chapter 3 >Revised Text: >1. In section 3.7.6.2 of ptc/01-06-10 in the second to last >paragraph, >remove >the first sentence which reads: > >"Attempting to use a LocalObject to create a DII request results in a >NO_IMPLEMENT system exception with standard minor code 4." > >2. Add the following bullet to the bullet list immediately preceding >the >second to >last paragraph in section 3.7.6.2 of ptc/01-06-01: > > "o create_request - returns a request object for the local >interface" > >3. In Table 4-3 of ptc/01-06-10 remove the row for minor code 4 >under NO_IMPLEMENT. I agree with the resolution as far as it goes, but I have some related concerns on the Java side. An implementation of DII on local objects in java can be built easily enough using reflection, so long as the arguments in the arg_list in the create_request call (or the calls to add_arg) are in the expected left-to-right order in which the method arguments were defined. If they are not in order, significant contortions in the code would be required to find the correct type information, since arg names are not available through the Java reflection APIs. About the only way to deal with the ordering is to get the InterfaceDef for the local interface and then check the names from the OperationDefs in the FullInterfaceDescription. This also points to a use for _get_interface_def support on local interfaces, but I'd like to keep these separate, so that the use of DII does not require _get_interface_def in the implementation of DII on local interfaces. Given the ordering difficulty, I would like to be able to say clearly that an ORB only supports DII with the arguments in the expected order. The CORBA 2.5 spec says the following in section 7.2.1 "create_request" near the bottom of page 7-6: "An implementation of the request services may relax the order constraint (and allow arguments to be specified out of order) by doing ordering based upon argument name." Similar language appears in section 7.2.2 "add_arg" on page 7-8. I think this is an unfortunate piece of language in the spec. Clearly a portable use of DII should ignore this and always make DII calls with arguments in the correct order. However, what should an implementation do, if some clients may occasionally pass arguments in the wrong order? Any attempt to detect ordering is almost as expensive as supporting out-of-order arguments. I would either like the ordering relaxation removed from the spec, or else have a statement added that relying on argument names instead of ordering is not portable and may result in errors that cannot be detected by the ORB implementation, since I would not plan on implementing an ORB that supports relaxed ordering here. It may also be desirable to implement _get_interface_def, since DII clients in many cases need to look at the InterfaceDef in order to correctly make DII calls. I think this is also relevant for scripting languages, since they may wish to inform the user of exactly what arguments are expected, and may need to deal with converting untyped data into strongly typed data as required for the DII invocation. There is an additional difficulty here in finding the repository id for a local interface in Java. For normal objects, invocations always start with a stub, which implements org.omg.CORBA.portable.ObjectImpl. ObjectImpl is an abstract class which supports the String[] _ids() method, which returns all of the repository IDs of interfaces supported by this stub. The code generated for a skeleton extends ObjectImpl and implements _ids(). _ids()[0] gives the MDI, so the full InterfaceDef can be obtained from a suitable IR (and of course this is what _get_interface_def should do). However, in the local case there is no stub: the implementation simply implements the java interface generated for the IDL local interface directly. The only way that is currently defined to get the repository ID information is to search up the inheritance graph looking for the MDI, then use the name of the MDI to construct the name of the corresponding Helper class, which provides the repository ID information. Perhaps the most straightforward way to fix this problem is to make org.omg.CORBA.LocalObject an abstract class, with an abstract String[] _ids() method, much like the current ObjectImpl class. We should also then require the generation of a local implementation base class that looks something like: class LocalBase extends org.omg.CORBA.LocalObject implements { private String[] _type_ids() = { ... } public String[] _ids() { return _type_ids.clone() ; } } The implementer of a local interface then simply writes class MyImpl extends LocalBase { // implement the declared methods } and provides any desired constructors. Finally, there is one additional problem: where do we put the implementation? The DII _create_request operation is implemented by the delegate accessed through ObjectImpl in the normal interface case. However, local interfaces do not extend ObjectImpl and do not have a delegate. We (at Sun) cannot put the code into org.omg.CORBA.LocalObject, since that would dictate the implementation of DII on local interfaces for all ORB vendors. This code will be significant in size, especially since a good implementation will want to take advantage of the reflection optimizations in JDK 1.4 and later, which may require caching This will require introducing some kind of LocalObjectDelegate into the IDL to Java mapping. The same kind of delegation model was introduced in the Java to IDL mapping for javax.rmi.PortableRemoteObject and the javax.rmi.CORBA classes. This delegate will need to provide implementations of _get_interface_def and _create_request. In summary, I think there are three related issues that need to be resolved: 1. Clean up the discussion about argument ordering (core RTF). 2. Introduce a generated LocalBase class so that the repository ID information is available for local interface implementations (Java RTF). 3. Introduce a LocalObjectDelegate (probably in org.omg.CORBA.portable) to allow substitutability of the implementations of _get_interface, _get_interface_def and both forms of _create_request (Java RTF). Ken. Date: Tue, 9 Oct 2001 17:04:11 +1000 (EST) From: Michi Henning To: Ken Cavanaugh cc: orb_revision@omg.org, jishnu_mukerji@hp.com, java-rtf@omg.org, corba-dev@Sun.COM Subject: Re: Proposed resolution for issue 3177 In-Reply-To: <200110082342.f98Ngr318173@ha1sca-mail1.SFBay.Sun.COM> Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ?@:!!-'5!!>Yh!!~RPe9 On Mon, 8 Oct 2001, Ken Cavanaugh wrote: > I think this is an unfortunate piece of language in the spec. I agree. To me, it seems that requiring the application to supply arguments in the correct order is no great burden and, as you say, makes the DII implementation a lot simpler. I'd say let's ditch this. > It may also be desirable to implement _get_interface_def, since DII clients > in many cases need to look at the InterfaceDef in order to > correctly make DII calls. I think this is also relevant for > scripting languages, since they may wish to inform the user of > exactly what arguments are expected, and may need to deal with > converting untyped data into strongly typed data as required for the > DII invocation. Completely agree. Given that Jishnu just spent a lot of effort to fix the IFR for local interfaces, it would seem silly in the extreme to prohibit calling _get_interface on local interfaces. > Perhaps the most straightforward way to fix this problem is to make > org.omg.CORBA.LocalObject an abstract class, with an abstract > String[] _ids() method, > much like the current ObjectImpl class. We should also then require > the generation of a local implementation base class that looks > something like: > > class LocalBase extends org.omg.CORBA.LocalObject > implements { > > private String[] _type_ids() = { ... } > > public String[] _ids() > { > return _type_ids.clone() ; > } > } > > The implementer of a local interface then simply writes > > class MyImpl extends LocalBase { > > // implement the declared methods > } > > and provides any desired constructors. This look s good to me. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi Date: Tue, 9 Oct 2001 16:51:06 +0200 From: 520065607613-0001@t-online.de (Frank Pilhofer) To: Jishnu Mukerji Cc: orb_revision@omg.org Subject: Re: Proposed resolution for issue 3177 Message-ID: <20011009165106.A1617@rose.fpx.de> Reply-To: Frank Pilhofer References: <3BC213B0.D06EBF27@hp.com> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3BC213B0.D06EBF27@hp.com>; from jishnu_mukerji@hp.com on Mon, Oct 08, 2001 at 04:59:28PM -0400 X-Sender: 520065607613-0001@t-dialin.net Content-Type: text/plain; charset=us-ascii X-UIDL: "S^N!!K"H!!6X3!! Jishnu Mukerji wrote: > > This one is to check if everyone is awake, and if not then to provoke > them to wake up:-) > Just found this one in my "junk" mailfolder, which this thread was assigned to because of an ill-designed procmail rule. > > The following resolution will appear in the vote that will go out on > Friday 10/12 unless there is serious technical objection to it. > [Re: local interfaces and the DII] I do. I advise against supporting the DII for local interfaces. I think this issue is a little thorny. It just does not ring right. Yet the only technical reason that I can bring forward at the moment is that local interfaces are allowed to take native values for parameters, which you cannot pass via DII. So you'll have to limit DII usage on local inter- faces anyway (e.g. you could not call activate_object on the POA). The point also seems silly to me for the reason that we - then - also should allow local interfaces to be implemented using DSI. Oh yes, and DII access to valuetypes, while we're at it! Let's face it, local objects are different from objects. As someone with a scripting language on top of a C++ ORB background, I reason against it. Frank -- Frank Pilhofer ........................................... fp@fpx.de Life is a lemon and I want my money back. - Meat Loaf Sender: jon@floorboard.com Message-ID: <3BC32D05.4A1F18B9@biggar.org> Date: Tue, 09 Oct 2001 09:59:49 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Frank Pilhofer CC: Jishnu Mukerji , orb_revision@omg.org Subject: Re: Proposed resolution for issue 3177 References: <3BC213B0.D06EBF27@hp.com> <20011009165106.A1617@rose.fpx.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: YD&e9f!N!!E;l!!B(>!! Frank Pilhofer wrote: > > The following resolution will appear in the vote that will go out on > > Friday 10/12 unless there is serious technical objection to it. > > > > [Re: local interfaces and the DII] > > I do. I advise against supporting the DII for local interfaces. I > think this issue is a little thorny. It just does not ring right. Yet > the only technical reason that I can bring forward at the moment is that > local interfaces are allowed to take native values for parameters, which > you cannot pass via DII. So you'll have to limit DII usage on local inter- > faces anyway (e.g. you could not call activate_object on the POA). That's a very good point. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 09 Oct 2001 13:08:41 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard SSO Staff, Florham Park NJ, USA X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Biggar Cc: Frank Pilhofer , orb_revision@omg.org Subject: Re: Proposed resolution for issue 3177 References: <3BC213B0.D06EBF27@hp.com> <20011009165106.A1617@rose.fpx.de> <3BC32D05.4A1F18B9@biggar.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: oo!!!]2ad9"J!"!dbNd9 Jonathan Biggar wrote: > > Frank Pilhofer wrote: > > > The following resolution will appear in the vote that will go out on > > > Friday 10/12 unless there is serious technical objection to it. > > > > > > > [Re: local interfaces and the DII] > > > > I do. I advise against supporting the DII for local interfaces. I > > think this issue is a little thorny. It just does not ring right. Yet > > the only technical reason that I can bring forward at the moment is that > > local interfaces are allowed to take native values for parameters, which > > you cannot pass via DII. So you'll have to limit DII usage on local inter- > > faces anyway (e.g. you could not call activate_object on the POA). > > That's a very good point. I am glad we are having this discussion. Would it make sense then to put a resolution to close issue 3177 no change with the reason described above for that action? Or would folks like to allow DII invocation of only those local interfaces operations that did not involve any native types? Thoughts? Jishnu. Date: Mon, 12 Nov 2001 15:25:13 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Issue 3177: DII support for local interfaces To: orb_revision@omg.org Cc: ken.cavanaugh@sun.com MIME-Version: 1.0 Content-MD5: k1RL2xGZEQ0j7F1/ogZYxw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: jhP!!5\I!!4@i!!';5e9 Jishnu asked for comments on closing this issue in an email dated October 9, 2001. I sent an earlier email discussing some of the aspects of supporting this feature in Java, but I am not particularly committed to implementing it. It seems to me that the real key to the discussion here is that Michi proposed adding DII support in this case to aid CORBA scripting languages, but the comments from Frank indicate that his experience with scripting language implementation did not require this. It seems that unless someone else has a strong opinion on this, we do not have a good use case for this feature. The other issue raised was just that DII cannot be used to call local interfaces that take native types as arguments, since natives can't be placed in an Any. I agree that this is a limitation, but we certainly could set things up so that only local interfaces that did not use natives could be invoked using DII. But I see no compelling reason to do this. So, in the absence of a strong use case, I agree that we should close this one no change. Ken.