Issue 3432: ORB access needed in IDL for Interceptors (interceptors-rtf) Source: Red Hat (Mr. Robert Kukura, rk(at)theep.net) Nature: Uncategorized Issue Severity: Summary: I would like us to seriously consider a different option - to change ORB >itself to be a local interface rather than a pseudo-object. If we were >starting from scratch, I see no reason that we wouldn't do it that way. >I'd like to know what the implications are of switching it to a local >interface now. Resolution: closed issue, duplicate od issue 3403 Revised Text: Actions taken: March 17, 2000: received issue April 5, 2000: closed issue Discussion: End of Annotations:===== X-Sender: jeff@mailhost.persistence.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 17 Mar 2000 15:12:43 -0800 To: interceptors-ftf@omg.org From: Jeff Mischkinsky Subject: Re: ORB access needed in IDL for Interceptors Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: $Ycd9]L+!!=#U!!@6Q!! At 06:12 AM 3/10/00, Bob Kukura wrote: >I would like us to seriously consider a different option - to change ORB >itself to be a local interface rather than a pseudo-object. If we were >starting from scratch, I see no reason that we wouldn't do it that way. >I'd like to know what the implications are of switching it to a local >interface now. I agree if that if we were starting from scratch we would probably take this kind of approach. But my feeling is that pursuing an evolutionary path might be more acceptable and allow us to discover and solve problems as they come up. I suspect that as usual, some "non-obvious" side effects will arise. (Dealing with the particularities of the various language mappings is certainly an obvious one. see below for Java.) The approach I'd like to suggest is starting by defining a "proxyORB" local interface which is responsible for delivering the "standard" operations currently defined on ORB. My assumption is that it could easily be implemented by delegating to the "psuedoORB implementation" that all currently have to provide. The advantage, of course, is that its upwardly compatible, possibly with the exception of figuring out how one gets the reference to the proxyORB. If one used the current pseudoORB as the factory, then we'd have to add one more PIDL op to it. The choice of whether to only add "new" stuff to the proxyORB would have to be made on a case by case basis. I do like the goal of eventually switching everyone over to using it. I'm not sure that Bob's suggestion for the "radical" approach would really save that much. From a practical point of view, vendors will almost certainly have to support both implementations in order not to break existing code, for quite some time. I think using native is a bad idea. Native is basically an "honest" substitute for PIDL. A native IDL type is one whose language mapping is specified only by the language mapping and is completely arbitrary. (At least with PIDL there is a (weak) assumption that the language mapping will usually follow the normal pattern for that language. Taking the TypeCode approach would also be a major change and requires changing the IDL language. I think this would only be warranted if we couldn't come up with another approach. From a practical point of view, it's probably not much different from the native approach because you would still have to decide and specify the language mapping for ORB for each individual language. >I don't know of any issues related to the C++ mapping. Do other >language mappings, such as Java, use different pseudo-IDL, or deviate >from standard mapping rules? I expect there to be some issues like >this, but I think its worth an attempt to come up with a creative >solution that gets this right for CORBA 3.0. This might involve a >common base ORB local inteface, with some language mappings deriving >extended local interfaces. Java has a bunch of "extra" methods on the ORB: // Additional operations that only appear in the Java mapping TypeCode get_primitive_tc(in TCKind tcKind); ExceptionList create_exception_list(); ContextList create_context_list(); Environment create_environment(); Current get_current(); Any create_any(); OutputStream create_output_stream(); void connect(Object obj); void disconnect(Object obj); Object get_value_def(in String repid); void set_delegate(Object wrapper); // additional methods for ORB initialization go here, but only // appear in the mapped Java (seeSection 1.21.9, "ORB Initialization) // Java signatures // public static ORB init(Strings[] args, Properties props); // public static ORB init(Applet app, Properties props); // public static ORB init(); // abstract protected void set_parameters(String[] args, // java.util.Properties props); // abstract protected void set_parameters(java.applet.Applet app, // java.util.Properties props); jeff Jeff Mischkinsky email: jeff@persistence.com Senior Software Architect voice: +1(650)372-3604 Persistence Software - The Engine for E-Commerce 1720 S. Amphlett Blvd. fax: +1(650)341-8432 San Mateo, CA 94402 web: http://www.persistence.com Jeff Mischkinsky email: jeff@persistence.com Senior Software Architect Persistence Software, Inc. voice: +1(650)372-3604 1720 S. Amphlett Blvd. fax: +1(650)341-8432 San Mateo, CA 04402 web: http://www.persistence.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: ORB access needed in IDL for Interceptors Date: Mon, 20 Mar 2000 09:29:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 4B%e9a&[d9418e9QSGe9 Jeff, I agree with you that the "local" approach, while attractive as an endpoint, could present serious migration problems. However I have difficulty with the ProxyORB solution. The main difficulty I see is that it results in two "ORB" interfaces in each language binding. Not only does this require more machinery in each implementation, but it adds considerable complexity to document for users, making CORBA even more complex than it already is. Done carefully, either the "native" or "typecode-like" approaches will have minimal effect on both users and vendors. Of these, the "native" approach seems cleanest. Someone else already pointed out that we could specify that the language bindings for the native ORB could be mandated to exactly match the prior language bindings for the PIDL orb. The end result is that the only external effect might be to require the addition of ORB to the IR - something also required in the other approaches. Paul > -----Original Message----- > From: Jeff Mischkinsky [mailto:jeff@persistence.com] > Sent: Friday, March 17, 2000 6:13 PM > To: interceptors-ftf@omg.org > Subject: Re: ORB access needed in IDL for Interceptors > > > > At 06:12 AM 3/10/00, Bob Kukura wrote: > >I would like us to seriously consider a different option - > to change ORB > >itself to be a local interface rather than a pseudo-object. > If we were > >starting from scratch, I see no reason that we wouldn't do > it that way. > >I'd like to know what the implications are of switching it to a > local > >interface now. > > I agree if that if we were starting from scratch we would > probably take > this kind of approach. But my feeling is that pursuing an > evolutionary path > might be more acceptable and allow us to discover and solve > problems as > they come up. I suspect that as usual, some "non-obvious" > side effects will > arise. (Dealing with the particularities of the various > language mappings > is certainly an obvious one. see below for Java.) > > The approach I'd like to suggest is starting by defining a > "proxyORB" local > interface which is responsible for delivering the "standard" > operations > currently defined on ORB. My assumption is that it could easily be > implemented by delegating to the "psuedoORB implementation" that all > > currently have to provide. > > The advantage, of course, is that its upwardly compatible, > possibly with > the exception of figuring out how one gets the reference to > the proxyORB. > If one used the current pseudoORB as the factory, then we'd > have to add one > more PIDL op to it. > > The choice of whether to only add "new" stuff to the proxyORB > would have to > be made on a case by case basis. I do like the goal of > eventually switching > everyone over to using it. > > I'm not sure that Bob's suggestion for the "radical" approach > would really > save that much. From a practical point of view, vendors will almost > certainly have to support both implementations in order not to break > > existing code, for quite some time. > > I think using native is a bad idea. Native is basically an "honest" > substitute for PIDL. A native IDL type is one whose language > mapping is > specified only by the language mapping and is completely > arbitrary. (At > least with PIDL there is a (weak) assumption that the > language mapping will > usually follow the normal pattern for that language. > > Taking the TypeCode approach would also be a major change and > requires > changing the IDL language. I think this would only be warranted if > we > couldn't come up with another approach. From a practical > point of view, > it's probably not much different from the native approach > because you would > still have to decide and specify the language mapping for ORB > for each > individual language. > > > >I don't know of any issues related to the C++ mapping. Do other > >language mappings, such as Java, use different pseudo-IDL, or > deviate > >from standard mapping rules? I expect there to be some issues like > >this, but I think its worth an attempt to come up with a creative > >solution that gets this right for CORBA 3.0. This might involve a > >common base ORB local inteface, with some language mappings > deriving > >extended local interfaces. > > Java has a bunch of "extra" methods on the ORB: > // Additional operations that only appear in the Java mapping > TypeCode get_primitive_tc(in TCKind tcKind); > ExceptionList create_exception_list(); > ContextList create_context_list(); > Environment create_environment(); > Current get_current(); > Any create_any(); > OutputStream create_output_stream(); > void connect(Object obj); > void disconnect(Object obj); > Object get_value_def(in String repid); > void set_delegate(Object wrapper); > // additional methods for ORB initialization go here, but only > // appear in the mapped Java (seeSection 1.21.9, "ORB > Initialization) > // Java signatures > // public static ORB init(Strings[] args, Properties props); > // public static ORB init(Applet app, Properties props); > // public static ORB init(); > // abstract protected void set_parameters(String[] args, > // java.util.Properties props); > // abstract protected void set_parameters(java.applet.Applet app, > // java.util.Properties props); > > jeff > Jeff Mischkinsky email: jeff@persistence.com > Senior Software Architect voice: +1(650)372-3604 > Persistence Software - The Engine for E-Commerce > 1720 S. Amphlett Blvd. fax: +1(650)341-8432 > San Mateo, CA 94402 web: > http://www.persistence.com > > > > Jeff Mischkinsky email: jeff@persistence.com > Senior Software Architect > Persistence Software, Inc. voice: +1(650)372-3604 > 1720 S. Amphlett Blvd. fax: +1(650)341-8432 > San Mateo, CA 04402 web: http://www.persistence.com > From: Jeffrey Mischkinsky Message-Id: <200003210241.SAA18541@wheel.dcn.davis.ca.us> Subject: Re: ORB access needed in IDL for Interceptors To: paulk@roguewave.com (Paul Kyzivat) Date: Mon, 20 Mar 2000 18:41:42 -0800 (PST) Cc: interceptors-ftf@omg.org In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD07@bos1.noblenet.com> from "Paul Kyzivat" at Mar 20, 2000 09:29:00 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~Z[d9:] > Jeff, > > I agree with you that the "local" approach, while attractive as an > endpoint, > could present serious migration problems. I don't understand how there could be migration problems, serious or otherwise. We create a new interface "local foo_orb..." which has a set of operations that "happen" to match the operations and semantics of operations that are currently only available through language mappings of the ORB PIDL. A user may choose to use the new functionality or not. Secretly, the implementation of these new operations, delegates to the existing implementation that is already found in everyone's product. The only real complication I can see if figuring out what the "factory" is for foo_orb. At some distant time in the future, we choose to get rid of the ORB PIDL, but I wouldn't hold my breathe. It does result in 2 different "ORB" interfaces, but the additional machinery is quite minimal. foo_orb is regular IDL, so doesn't require any special hacks, etc. The implementation that delegates to the pidl orb implementation is pretty trivial and minimal also. native is a total hack. Every time someone adds a new operation they should have to go through every language mapping and specify the mapping. (And you know how successful we've been doing that. :-) I don't think adding a new regular interface, be it standard or otherwise, requires any changes to the IR. Correct me if i'm wrong, but aren't there rules against using native types as parameters to regular IDL operations? or at least severe restrictions on where native types can be used? jeff > > However I have difficulty with the ProxyORB solution. > The main difficulty I see is that it results in two "ORB" interfaces > in each > language binding. Not only does this require more machinery in each > implementation, but it adds considerable complexity to document for > users, > making CORBA even more complex than it already is. > > Done carefully, either the "native" or "typecode-like" approaches > will have > minimal effect on both users and vendors. Of these, the "native" > approach > seems cleanest. Someone else already pointed out that we could > specify that > the language bindings for the native ORB could be mandated to > exactly match > the prior language bindings for the PIDL orb. The end result is that > the > only external effect might be to require the addition of ORB to the > IR - > something also required in the other approaches. > > Paul > > > -----Original Message----- > > From: Jeff Mischkinsky [mailto:jeff@persistence.com] > > Sent: Friday, March 17, 2000 6:13 PM > > To: interceptors-ftf@omg.org > > Subject: Re: ORB access needed in IDL for Interceptors > > > > > > > > At 06:12 AM 3/10/00, Bob Kukura wrote: > > >I would like us to seriously consider a different option - > > to change ORB > > >itself to be a local interface rather than a pseudo-object. > > If we were > > >starting from scratch, I see no reason that we wouldn't do > > it that way. > > >I'd like to know what the implications are of switching it to a > local > > >interface now. > > > > I agree if that if we were starting from scratch we would > > probably take > > this kind of approach. But my feeling is that pursuing an > > evolutionary path > > might be more acceptable and allow us to discover and solve > > problems as > > they come up. I suspect that as usual, some "non-obvious" > > side effects will > > arise. (Dealing with the particularities of the various > > language mappings > > is certainly an obvious one. see below for Java.) > > > > The approach I'd like to suggest is starting by defining a > > "proxyORB" local > > interface which is responsible for delivering the "standard" > > operations > > currently defined on ORB. My assumption is that it could easily be > > > implemented by delegating to the "psuedoORB implementation" that > all > > currently have to provide. > > > > The advantage, of course, is that its upwardly compatible, > > possibly with > > the exception of figuring out how one gets the reference to > > the proxyORB. > > If one used the current pseudoORB as the factory, then we'd > > have to add one > > more PIDL op to it. > > > > The choice of whether to only add "new" stuff to the proxyORB > > would have to > > be made on a case by case basis. I do like the goal of > > eventually switching > > everyone over to using it. > > > > I'm not sure that Bob's suggestion for the "radical" approach > > would really > > save that much. From a practical point of view, vendors will > almost > > certainly have to support both implementations in order not to > break > > existing code, for quite some time. > > > > I think using native is a bad idea. Native is basically an > "honest" > > substitute for PIDL. A native IDL type is one whose language > > mapping is > > specified only by the language mapping and is completely > > arbitrary. (At > > least with PIDL there is a (weak) assumption that the > > language mapping will > > usually follow the normal pattern for that language. > > > > Taking the TypeCode approach would also be a major change and > > requires > > changing the IDL language. I think this would only be warranted if > we > > couldn't come up with another approach. From a practical > > point of view, > > it's probably not much different from the native approach > > because you would > > still have to decide and specify the language mapping for ORB > > for each > > individual language. > > > > > > >I don't know of any issues related to the C++ mapping. Do other > > >language mappings, such as Java, use different pseudo-IDL, or > deviate > > >from standard mapping rules? I expect there to be some issues > like > > >this, but I think its worth an attempt to come up with a creative > > >solution that gets this right for CORBA 3.0. This might involve > a > > >common base ORB local inteface, with some language mappings > deriving > > >extended local interfaces. > > > > Java has a bunch of "extra" methods on the ORB: > > // Additional operations that only appear in the Java mapping > > TypeCode get_primitive_tc(in TCKind tcKind); > > ExceptionList create_exception_list(); > > ContextList create_context_list(); > > Environment create_environment(); > > Current get_current(); > > Any create_any(); > > OutputStream create_output_stream(); > > void connect(Object obj); > > void disconnect(Object obj); > > Object get_value_def(in String repid); > > void set_delegate(Object wrapper); > > // additional methods for ORB initialization go here, but only > > // appear in the mapped Java (seeSection 1.21.9, "ORB > Initialization) > > // Java signatures > > // public static ORB init(Strings[] args, Properties props); > > // public static ORB init(Applet app, Properties props); > > // public static ORB init(); > > // abstract protected void set_parameters(String[] args, > > // java.util.Properties props); > > // abstract protected void set_parameters(java.applet.Applet app, > > // java.util.Properties props); > > > > jeff > > Jeff Mischkinsky email: jeff@persistence.com > > Senior Software Architect voice: +1(650)372-3604 > > Persistence Software - The Engine for E-Commerce > > 1720 S. Amphlett Blvd. fax: +1(650)341-8432 > > San Mateo, CA 94402 web: > http://www.persistence.com > > > > > > > > Jeff Mischkinsky email: jeff@persistence.com > > Senior Software Architect > > Persistence Software, Inc. voice: +1(650)372-3604 > > 1720 S. Amphlett Blvd. fax: +1(650)341-8432 > > San Mateo, CA 04402 web: > http://www.persistence.com > > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: Jeffrey Mischkinsky cc: interceptors-ftf@omg.org Message-ID: <852568A9.004C3264.00@d54mta08.raleigh.ibm.com> Date: Tue, 21 Mar 2000 07:44:08 -0600 Subject: Re: ORB access needed in IDL for Interceptors Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: oR~e9TRPe9hI*!!$4G!! Jeffrey Mischkinsky on 03/20/2000 08:41:42 PM > > 'Paul Kyzivat' writes: > > > > Jeff, > > > > I agree with you that the "local" approach, while attractive as an endpoint, > > could present serious migration problems. > > I don't understand how there could be migration problems, serious or > otherwise. > > We create a new interface "local foo_orb..." which has a set of operations that > "happen" to match the operations and semantics of operations that are > currently only available through language mappings of the ORB PIDL. > A user may choose to use the new functionality or not. > > Secretly, the implementation of these new operations, delegates to the > existing implementation that is already found in everyone's product. > The only real complication I can see if figuring out what the "factory" is > for foo_orb. I think we'd have to provide 2 "factories". 1. On the PIDL ORB, provide a getProxy method. 2. Define another ORB_Init method that returns the proxyORB instead of the PIDL ORB. I think that would cover us. From the PIDL ORB you could get the proxyORB, but from the proxyORB you can't get the PIDL ORB (I don't see why we'd want to, anyway). > > At some distant time in the future, we choose to get rid of the ORB > PIDL, > but I wouldn't hold my breathe. > > It does result in 2 different "ORB" interfaces, but the additional machinery > is quite minimal. foo_orb is regular IDL, so doesn't require any > special > hacks, etc. The implementation that delegates to the pidl orb implementation > is pretty trivial and minimal also. > > native is a total hack. Every time someone adds a new operation they should > have to go through every language mapping and specify the > mapping. (And > you know how successful we've been doing that. :-) I disagree with you. Native is not a hack. Well... no more than PIDL is anyway, and since we're trying to remedy a PIDL situation, I see no problem with using native to do so. You say "Every time someone adds a new operation they should have to go through every language mapping and specify the mapping." This applies whether we use native or the dual IDL/PIDL definition. Since ORB would still be defined in PIDL, even though we can add the new operation to the proxyORB IDL, we still have to explicitly add the same operation to the PIDL, which means specifying the mapping in every language. > > I don't think adding a new regular interface, be it standard or otherwise, > requires any changes to the IR. > > Correct me if i'm wrong, but aren't there rules against using native types > as parameters to regular IDL operations? or at least severe > restrictions > on where native types can be used? The only rule against native types as parameters that I could find was a proviso allowing them to be illegal in remote calls, which is a necessary restriction in our case. Page 3-10: "A native type may be used to define operation parameters and results. However, there is no requirement that values of the type be permitted in remote invocations, either directly or as a component of a constructed type. Any attempt to transmit a value of a native type in a remote invocation may raise the MARSHAL standard exception." > > jeff Russell Butek butek@us.ibm.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: ORB access needed in IDL for Interceptors Date: Tue, 21 Mar 2000 10:06:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: kCf!!6bW!!hN#e97A-!! As I stated before, I object to the proxy primarily because it adds additional complexity for users to deal with. Perhaps someone that has written a book on CORBA (e.g. Michi, or Jon Siegel) would like to comment on how this kind of change would contribute to the ease of teaching and learning CORBA. Certainly I don't relish the thought of trying to explain this in my user manuals or during support calls. I am not wed to native - I am simply resisting having two orb interfaces. I agree we ideally should have a way to describe the operations in a language independent way so we don't have to rev all the language bindings every time we add something. Maybe making ORB a local interface is preferable, but I guess that is a problem because language bindings have not mapped everyting in the standard way. But we might be better off dealing with that. Paul > -----Original Message----- > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > Sent: Tuesday, March 21, 2000 8:44 AM > To: Jeffrey Mischkinsky > Cc: interceptors-ftf@omg.org > Subject: Re: ORB access needed in IDL for Interceptors > > Jeffrey Mischkinsky on > 03/20/2000 08:41:42 > PM > > > > 'Paul Kyzivat' writes: > > > > > > Jeff, > > > > > > I agree with you that the "local" approach, while attractive as > an > endpoint, > > > could present serious migration problems. > > > > I don't understand how there could be migration problems, serious > or > > otherwise. > > > > We create a new interface "local foo_orb..." which has a set of > operations that > > "happen" to match the operations and semantics of > operations that are > > currently only available through language mappings of the ORB > PIDL. > > A user may choose to use the new functionality or not. > > > > Secretly, the implementation of these new operations, > delegates to the > > existing implementation that is already found in everyone's > product. > > The only real complication I can see if figuring out what > the "factory" > is > > for foo_orb. > > I think we'd have to provide 2 "factories". > 1. On the PIDL ORB, provide a getProxy method. > 2. Define another ORB_Init method that returns the proxyORB > instead of the > PIDL ORB. > > I think that would cover us. From the PIDL ORB you could get > the proxyORB, > but from the proxyORB you can't get the PIDL ORB (I don't see > why we'd want > to, anyway). > > > > > > At some distant time in the future, we choose to get rid of > the ORB PIDL, > > but I wouldn't hold my breathe. > > > > It does result in 2 different "ORB" interfaces, but the additional > machinery > > is quite minimal. foo_orb is regular IDL, so doesn't > require any special > > hacks, etc. The implementation that delegates to the pidl orb > implementation > > is pretty trivial and minimal also. > > > > native is a total hack. Every time someone adds a new operation > they > should > > have to go through every language mapping and specify the > mapping. (And > > you know how successful we've been doing that. :-) > > I disagree with you. Native is not a hack. Well... no more > than PIDL is > anyway, and since we're trying to remedy a PIDL situation, I > see no problem > with using native to do so. You say "Every time someone adds a new > operation they should have to go through every language > mapping and specify > the mapping." This applies whether we use native or the dual > IDL/PIDL > definition. Since ORB would still be defined in PIDL, even > though we can > add the new operation to the proxyORB IDL, we still have to > explicitly add > the same operation to the PIDL, which means specifying the > mapping in every > language. > > > > > > I don't think adding a new regular interface, be it standard or > otherwise, > > requires any changes to the IR. > > > > Correct me if i'm wrong, but aren't there rules against using > native > types > > as parameters to regular IDL operations? or at least severe > restrictions > > on where native types can be used? > > The only rule against native types as parameters that I could > find was a > proviso allowing them to be illegal in remote calls, which is > a necessary > restriction in our case. > > Page 3-10: > > "A native type may be used to define operation parameters and > results. > However, there > is no requirement that values of the type be permitted in remote > invocations, either > directly or as a component of a constructed type. Any attempt > to transmit a > value of a > native type in a remote invocation may raise the MARSHAL standard > exception." > > > > > > jeff > > > > Russell Butek > butek@us.ibm.com > > Date: Tue, 21 Mar 2000 10:24:31 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: butek@us.ibm.com Cc: Jeffrey Mischkinsky , interceptors-ftf@omg.org Subject: Re: ORB access needed in IDL for Interceptors References: <852568A9.004C3264.00@d54mta08.raleigh.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: fl4e9"'=!!U4kd9BU4e9 butek@us.ibm.com wrote: > Jeffrey Mischkinsky on 03/20/2000 08:41:42 > PM > > > > > At some distant time in the future, we choose to get rid of the ORB PIDL, > > but I wouldn't hold my breathe. > > > > It does result in 2 different "ORB" interfaces, but the additional > machinery > > is quite minimal. foo_orb is regular IDL, so doesn't require any special > > hacks, etc. The implementation that delegates to the pidl orb > implementation > > is pretty trivial and minimal also. > > > > native is a total hack. Every time someone adds a new operation they > should > > have to go through every language mapping and specify the mapping. (And > > you know how successful we've been doing that. :-) > > I disagree with you. Native is not a hack. Well... no more than PIDL is > anyway, and since we're trying to remedy a PIDL situation, I see no problem > with using native to do so. You say "Every time someone adds a new > operation they should have to go through every language mapping and specify > the mapping." This applies whether we use native or the dual IDL/PIDL > definition. Since ORB would still be defined in PIDL, even though we can > add the new operation to the proxyORB IDL, we still have to explicitly add > the same operation to the PIDL, which means specifying the mapping in every > language. > Strictly speaking whether new operations have to be added to the PIDL ORB is a policy issue. We could take the position that no new operations shall be added to the PIDL ORB, they shall be added only to the IDL ORB, thus in effect starting the deprecation process of the PIDL ORB. If we do this then we won't have to explicitly specify mappings of each new operation in each implementation language anymore. While I am have not fully thought through every nook and cranny of this problem, in general I believe we should avoid using native as much as possible, for the same reason that we want to stop using PIDL. I agree that native is not a random hack, it does a specific thing. Native should be used only if there is a pressing need to introduce a type into the IDL type name space for something that looks very different in different implementation languages, from what one would get using standard language mappings. Jishnu. Reply-To: From: "Nick Sharman" To: Subject: RE: ORB access needed in IDL for Interceptors Date: Tue, 21 Mar 2000 15:48:03 -0000 Message-ID: <001c01bf934c$d7bc6970$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <852568A9.004C3264.00@d54mta08.raleigh.ibm.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: E5Qd9igZd9P)4e9[\!"! Russel Butek wrote (snipped): > > > native is a total hack. Every time someone adds a new operation they > should > > have to go through every language mapping and specify the mapping. (And > > you know how successful we've been doing that. :-) > > I disagree with you. Native is not a hack. Well... no more than PIDL is > anyway, and since we're trying to remedy a PIDL situation, I see > no problem > with using native to do so. You say "Every time someone adds a new > operation they should have to go through every language mapping > and specify > the mapping." This applies whether we use native or the dual IDL/PIDL > definition. Since ORB would still be defined in PIDL, even though we can > add the new operation to the proxyORB IDL, we still have to explicitly add > the same operation to the PIDL, which means specifying the > mapping in every > language. > There's one slight problem with native in this case: module CORBA { interface ORB // PIDL { exception InvalidName{}; ... }; }; If we write: module CORBA { native ORB; }; there's nowhere to hang the exception! So we would have to move it out into the CORBA namespace (incompatible change) or just define it explicitly in every mapping. The main disadvantage however is that it doesn't make things any better for the developer or the implementer; and perhaps worse since we've lost the PIDL that we use as a way of discussing the ORB operations in Ch.4 (and as a way of indicating that the language mappings have to deal with these things somehow). I prefer a genuine local interface, in addition to the PIDL ORB for some period, as it offers a way out of the hand-coding mess. However, this raises three issues: 1) Where do the local object's "factory" operations live? They can never be real IDL, so I think we will always be stuck with a non-IDL interface. It would be a pity to put them in CORBA::ORB, since we would like that to disappear eventually. 2) The language mappings don't always follow the normal mappings for the other operations. Is that historical accident, or are there real problems in using the real mappings in these cases? 3) Java, in particular, extends the PIDL-defined operations with a whole bunch more of useful stuff (typecode builders and so on). Can org.omg.CORBA.ProxyORB support more than the IDL-defined operations, or do we need some other non-IDL interface to do the job? Regards Nick From: Jeffrey Mischkinsky Message-Id: <200003211552.HAA27189@wheel.dcn.davis.ca.us> Subject: Re: ORB access needed in IDL for Interceptors To: butek@us.ibm.com Date: Tue, 21 Mar 2000 07:52:00 -0800 (PST) Cc: interceptors-ftf@omg.org In-Reply-To: <852568A9.004C3264.00@d54mta08.raleigh.ibm.com> from "butek@us.ibm.com" at Mar 21, 2000 07:44:08 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ='Ie9^89!!&#c!!p90e9 'butek@us.ibm.com' writes: > Jeffrey Mischkinsky on 03/20/2000 > 08:41:42 > PM > > > I think that would cover us. From the PIDL ORB you could get the > proxyORB, > but from the proxyORB you can't get the PIDL ORB (I don't see why > we'd want > to, anyway). I agree, it would kind of destroy the purpose of the exercise. > > At some distant time in the future, we choose to get rid of the ORB PIDL, > > but I wouldn't hold my breathe. > > > > It does result in 2 different "ORB" interfaces, but the additional > machinery > > is quite minimal. foo_orb is regular IDL, so doesn't require any special > > hacks, etc. The implementation that delegates to the pidl orb > implementation > > is pretty trivial and minimal also. > > > > native is a total hack. Every time someone adds a new operation they > should > > have to go through every language mapping and specify the mapping. (And > > you know how successful we've been doing that. :-) > > I disagree with you. Native is not a hack. Well... no more than PIDL is > anyway, and since we're trying to remedy a PIDL situation, I see no problem > with using native to do so. Is hackedness a transitive property? :-) I won't get into the history of how native came to be...see me over a beer some time. But I don't see that replacing PIDL with native is a step forward. At best, it's a sideways step. I don't see what advantage it buys us. > You say "Every time someone adds a new > operation they should have to go through every language mapping and > specify > the mapping." This applies whether we use native or the dual > IDL/PIDL > definition. Since ORB would still be defined in PIDL, even though > we can > add the new operation to the proxyORB IDL, we still have to > explicitly add > the same operation to the PIDL, which means specifying the mapping > in every > language. Actually, we don't have to ever touch the PIDL orb again, if we choose not to. We could decide that the first step towards transitioning people away from the PIDL orb is to only add new operations to the foo_orb. Eventually they'll just use the new guy in town. > > Correct me if i'm wrong, but aren't there rules against using native > types > > as parameters to regular IDL operations? or at least severe restrictions > > on where native types can be used? > > The only rule against native types as parameters that I could find was a > proviso allowing them to be illegal in remote calls, which is a necessary > restriction in our case. Good. Thanks for hunting it down. cheers, jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: nick.sharman@peerlogic.com cc: interceptors-ftf@omg.org Message-ID: <852568A9.0058869B.00@d54mta08.raleigh.ibm.com> Date: Tue, 21 Mar 2000 09:58:48 -0600 Subject: RE: ORB access needed in IDL for Interceptors Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: AF+e9M+Ne9-1*!!P1Je9 "Nick Sharman" on 03/21/2000 09:48:03 AM > > Russel Butek wrote (snipped): > > > > > native is a total hack. Every time someone adds a new operation they > > should > > > have to go through every language mapping and specify the mapping. (And > > > you know how successful we've been doing that. :-) > > > > I disagree with you. Native is not a hack. Well... no more than PIDL is > > anyway, and since we're trying to remedy a PIDL situation, I see > > no problem > > with using native to do so. You say "Every time someone adds a new > > operation they should have to go through every language mapping > > and specify > > the mapping." This applies whether we use native or the dual IDL/PIDL > > definition. Since ORB would still be defined in PIDL, even though we can > > add the new operation to the proxyORB IDL, we still have to explicitly add > > the same operation to the PIDL, which means specifying the > > mapping in every > > language. > > > There's one slight problem with native in this case: > > module CORBA { > interface ORB // PIDL > { > exception InvalidName{}; > ... > }; > }; > > If we write: > > module CORBA { > native ORB; > }; > > there's nowhere to hang the exception! So we would have to move it out into > the CORBA namespace (incompatible change) or just define it explicitly in > every mapping. Since ORB is PIDL, so is InvalidName, so there's no problem. We're not trying to put InvalidName into the IDL namespace, just ORB. So I think we're OK. But this DOES bring up a valid technical issue (everything else I've heard against native so far seems merely philosophical). Is there anything else that's defined within ORB that could potentially be needed as IDL? Until I (or anyone else) gets a chance to check, the native idea is on probation in my mind. > > The main disadvantage however is that it doesn't make things any > better for > the developer or the implementer; and perhaps worse since we've lost > the > PIDL that we use as a way of discussing the ORB operations in Ch.4 > (and as a > way of indicating that the language mappings have to deal with these things > somehow). I don't understand why folks think we've lost the PIDL way of discussing the ORB. Adding "native ORB;" does nothing with the ORB PIDL. It's still there. All it does is add ORB into the IDL namespace. > > I prefer a genuine local interface, in addition to the PIDL ORB for > some > period, as it offers a way out of the hand-coding mess. However, > this > raises three issues: > > 1) Where do the local object's "factory" operations live? > > They can never be real IDL, so I think we will always be stuck > with a non-IDL interface. It would be a pity to put them in CORBA::ORB, > since we would like that to disappear eventually. As I suggested, we could have two factories: 1. On the PIDL ORB, provide a getProxy method. 2. Define another ORB_Init method that returns the proxyORB instead of the PIDL ORB. The first is needed as long as we keep the PIDL ORB around. The second just mirrors how a PIDL ORB is created. Does anyone think these would be insufficient? > > 2) The language mappings don't always follow the normal mappings for > the > other operations. > > Is that historical accident, or are there real problems in using > the > real mappings in these cases? This is a big concern in my mind. Do we have anyone willing to exhaustively look at various mappings and confirm that an IDL proxyORB really works in each mapping? Jeff already did some of this for Java. > > 3) Java, in particular, extends the PIDL-defined operations with a > whole > bunch more of useful stuff (typecode builders and so on). > > Can org.omg.CORBA.ProxyORB support more than the IDL-defined operations, > or do we need some other non-IDL interface to do the job? Jeff suggested that we have a base ORB local interface and each language mapping that adds new items would extend this interface with their own IDL ORB. Does your concern go beyond this > > Regards > Nick > Russell Butek butek@us.ibm.com Date: Wed, 22 Mar 2000 09:49:40 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interceptors-ftf@omg.org Subject: RE: ORB access needed in IDL for Interceptors In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD16@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ]jmd9h!9e9aPRd9E82!! On Tue, 21 Mar 2000, Paul Kyzivat wrote: > Perhaps someone that has written a book on CORBA (e.g. Michi, or Jon Siegel) > would like to comment on how this kind of change would contribute to the > ease of teaching and learning CORBA. Certainly I don't relish the thought of > trying to explain this in my user manuals or during support calls. Me neither. As a pointed out during the Denver meeting, "I'd hate to have to explain this to students." > I am not wed to native - I am simply resisting having two orb interfaces. > I agree we ideally should have a way to describe the operations in a > language independent way so we don't have to rev all the language bindings > every time we add something. Maybe making ORB a local interface is > preferable, but I guess that is a problem because language bindings have not > mapped everyting in the standard way. But we might be better off dealing > with that. One other option we canvassed was to make the ORB available via the Current object. Would that improve things? Cheers, Michi. From: Jeffrey Mischkinsky Message-Id: <200003220107.RAA22125@wheel.dcn.davis.ca.us> Subject: Re: ORB access needed in IDL for Interceptors To: michi@ooc.com.au (Michi Henning) Date: Tue, 21 Mar 2000 17:07:05 -0800 (PST) Cc: paulk@roguewave.com (Paul Kyzivat), interceptors-ftf@omg.org In-Reply-To: from "Michi Henning" at Mar 22, 2000 09:49:40 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3end9hI1e9Q1@e9Ib"e9 'Michi Henning' writes: > > On Tue, 21 Mar 2000, Paul Kyzivat wrote: > > > Perhaps someone that has written a book on CORBA (e.g. Michi, or > Jon Siegel) > > would like to comment on how this kind of change would contribute > to the > > ease of teaching and learning CORBA. Certainly I don't relish the > thought of > > trying to explain this in my user manuals or during support calls. The easy way to explain it, is to ignore the PIDL orb and only describe the IDL ORB (assuming we make all the operations available.). You can delegate it to an appendix dealing with "legacy" programming practices. > > Me neither. As a pointed out during the Denver meeting, "I'd hate to > have > to explain this to students." > > > I am not wed to native - I am simply resisting having two orb > interfaces. > > I agree we ideally should have a way to describe the operations in > a > > language independent way so we don't have to rev all the language > bindings > > every time we add something. Maybe making ORB a local interface is > > preferable, but I guess that is a problem because language > bindings have not > > mapped everyting in the standard way. But we might be better off > dealing > > with that. > > One other option we canvassed was to make the ORB available via the > Current > object. Would that improve things? I'm not sure it would. It seems to me that the fundamental problem is > that the ORB is currently not IDL. How does changing where one get's the > reference to it help? jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 21 Mar 2000 21:27:23 -0500 (EST) From: Polar Humenn To: Michi Henning cc: Paul Kyzivat , interceptors-ftf@omg.org Subject: RE: ORB access needed in IDL for Interceptors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: \QKe9M8;!!p;(e9U/k!! On Wed, 22 Mar 2000, Michi Henning wrote: > On Tue, 21 Mar 2000, Paul Kyzivat wrote: > > One other option we canvassed was to make the ORB available via the > Current > object. Would that improve things? Don't you need the ORB to get the Current object? -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: ORB access needed in IDL for Interceptors Date: Wed, 22 Mar 2000 13:05:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: >*Ae9SK1e9p0"!!?Thd9 > From: Jeffrey Mischkinsky > The easy way to explain it, is to ignore the PIDL orb and > only describe > the IDL ORB (assuming we make all the operations available.). > > You can delegate it to an appendix dealing with "legacy" > programming practices. Perhaps that can be made reasonable, but then we must make it a goal. It must be possible to use an orb without needing to know about the PIDL form. And we have to be careful with the naming so it doesn't come across looking like a kludge. > > One other option we canvassed was to make the ORB available > via the Current > > object. Would that improve things? > I'm not sure it would. It seems to me that the fundamental > problem is that > the ORB is currently not IDL. How does changing where one > get's the reference to it help? I agree - I don't see how this helps. Date: Thu, 23 Mar 2000 08:58:34 +1000 (EST) From: Michi Henning To: Paul Kyzivat cc: interceptors-ftf@omg.org Subject: RE: ORB access needed in IDL for Interceptors In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD28@bos1.noblenet.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: <1U!!+1,!!13V!!'3]!! On Wed, 22 Mar 2000, Paul Kyzivat wrote: > > You can delegate it to an appendix dealing with "legacy" > > programming practices. > > Perhaps that can be made reasonable, but then we must make it a > goal. > It must be possible to use an orb without needing to know about the > PIDL form. And we have to be careful with the naming so it doesn't > come > across looking like a kludge. Yes. *Please*, let's be careful with that. I'm really concerned about this API turning into a maze of twisty little passages, all alike... > > > One other option we canvassed was to make the ORB available > > via the Current > > > object. Would that improve things? > > I'm not sure it would. It seems to me that the fundamental > > problem is that > > the ORB is currently not IDL. How does changing where one > > get's the reference to it help? > > I agree - I don't see how this helps. Me neither. Sorry for the red herring... 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 From: Jeffrey Mischkinsky Message-Id: <200003222323.PAA02325@wheel.dcn.davis.ca.us> Subject: Re: ORB access needed in IDL for Interceptors To: paulk@roguewave.com (Paul Kyzivat) Date: Wed, 22 Mar 2000 15:23:02 -0800 (PST) Cc: interceptors-ftf@omg.org In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD28@bos1.noblenet.com> from "Paul Kyzivat" at Mar 22, 2000 01:05:42 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: WHK!!9U8e9n!K!!*]`d9 'Paul Kyzivat' writes: > > > From: Jeffrey Mischkinsky > > > The easy way to explain it, is to ignore the PIDL orb and > > only describe > > the IDL ORB (assuming we make all the operations available.). > > > > You can delegate it to an appendix dealing with "legacy" > > programming practices. > > Perhaps that can be made reasonable, but then we must make it a > goal. That's mostly an issue of how you (a vendor) write your product manuals, isn't it? > It must be possible to use an orb without needing to know about the > PIDL form. This we can control,to some extent by making the local IDL ORB have a complete set of operations. (However there may still be a need for the existing PIDL simply because of what the "extensions" language mappings have made. (because it is PIDL, not IDL). > And we have to be careful with the naming so it doesn't come > across looking like a kludge. So you probably don't like fooORB or foo_orb in keeping with the famous naming conventions? :-) cheers, jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: interceptors-ftf@omg.org Message-ID: <852568B0.007B771B.00@d54mta08.raleigh.ibm.com> Date: Tue, 28 Mar 2000 16:20:11 -0600 Subject: PI issues #3403, 3432, 3450 Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: -!f!!5D4e9acY!!NAZ!! Just a little bookkeeping. These three issues are really the same: PI needs the ORB to be available in IDL: http://www.omg.org/issues/interceptors-ftf.html#Issue3403 ORB access needed in IDL for Interceptors: http://www.omg.org/issues/interceptors-ftf.html#Issue3432 Getting rid of ORB PIDL: http://www.omg.org/issues/interceptors-ftf.html#Issue3450 Would anyone take umbrage if I closed 3432 and 3450 in favor of 3403? Jeff, your name is on 3450. Bob, yours is on 3432. Russell Butek butek@us.ibm.com From: Jeffrey Mischkinsky Message-Id: <200003282348.PAA13807@wheel.dcn.davis.ca.us> Subject: Re: PI issues #3403, 3432, 3450 To: butek@us.ibm.com Date: Tue, 28 Mar 2000 15:48:20 -0800 (PST) Cc: interceptors-ftf@omg.org In-Reply-To: <852568B0.007B771B.00@d54mta08.raleigh.ibm.com> from "butek@us.ibm.com" at Mar 28, 2000 04:20:11 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: S)f!!IHN!!8)3!!'9^d9 Russ, I don't have any objection (you can have all the glory :-). Seriously i'm not sure why the other 2 got labelled as separate issues. I think both were meant as comments on 3403. I do think that the text that is associated with 3450 and 3432 should be transferred as the comments are very relevant. jeff 'butek@us.ibm.com' writes: > > > > Just a little bookkeeping. These three issues are really the same: > > PI needs the ORB to be available in IDL: > http://www.omg.org/issues/interceptors-ftf.html#Issue3403 > ORB access needed in IDL for Interceptors: > http://www.omg.org/issues/interceptors-ftf.html#Issue3432 > Getting rid of ORB PIDL: > http://www.omg.org/issues/interceptors-ftf.html#Issue3450 > > Would anyone take umbrage if I closed 3432 and 3450 in favor of > 3403? > Jeff, your name is on 3450. Bob, yours is on 3432. > > Russell Butek > butek@us.ibm.com > > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604