Issue 3450: Getting rid of ORB PIDL (interceptors-rtf) Source: (Mr. Jeff Mischkinsky, jmischki(at)dcn.davis.ca.us) Nature: Uncategorized Issue Severity: Summary: I think it would be worth discussing this at a slightly higher level. I have made the argument before that we're kidding ourselves by believing that we can convince people to throwout the existing PIDL infrastructure instantly. As engineers we KNOW that there are cleaner approaches, and that by using some of the newer features that we've added to IDL and by being a bit more clever we can probably produce a much better architecture. Resolution: closed issue, duplicate od issue 3403 Revised Text: Actions taken: March 24, 2000: received issue April 5, 2000: closed issue Discussion: End of Annotations:===== From: Jeffrey Mischkinsky Message-Id: <200003241811.KAA28440@wheel.dcn.davis.ca.us> Subject: Getting rid of ORB PIDL To: interceptors-ftf@omg.org Date: Fri, 24 Mar 2000 10:11:06 -0800 (PST) In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD58@bos1.noblenet.com> from "Paul Kyzivat" at Mar 24, 2000 12:13:53 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: c4Ke9/N;!!FS > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > > I guess this is my primary complaint ('worry' is perhaps a > > better word) > > with the IDL ORB approach. There is a lot of work involved > > in defining it. > > Do we have time for that in this FTF? Do we even have > > volunteers for that? > > I just spent a couple of minutes looking at the specific issues for > the C++ > language binding. My conclusion is that the issues are much the same > whether > we really "idl-ize" the orb interface or create an idl wrapper > class. > > The problem is that ORB has a bunch of operations that themselves > take PIDL > arguments. The troublesome PIDL things include: Request, NVList, > Context. > > So, we have a recursive problem. We can't make IDL versions of the > operations on these things (in either an IDL ORB or an IDL ORB > wrapper) > unless we make these real IDL. > > One workaround is to move all of the operations that touch these > things to > language specific extensions. > > Building a wrapper that doesn't support any of these, and then > forcing use > of the PIDL ORB to use them is another workaround. But this simply > leaves us > with a degraded idl interface and no way to deprecate the pidl. > > A third approach would simply be to make all the new interfaces we > are > defining PIDL as well, perhaps with instructions that the language > mappings > should follow the normal mappings. IMO this is better than the > alternatives. > > Paul > -- 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: <852568AC.0068CDDD.00@d54mta08.raleigh.ibm.com> Date: Fri, 24 Mar 2000 12:56:30 -0600 Subject: Re: Getting rid of ORB PIDL Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: $A\d9S on 03/24/2000 12:11:06 PM To: interceptors-ftf@omg.org cc: Subject: Getting rid of ORB PIDL Hi, Time for a new thread name. :-) I think it would be worth discussing this at a slightly higher level. I have made the argument before that we're kidding ourselves by believing that we can convince people to throwout the existing PIDL infrastructure instantly. As engineers we KNOW that there are cleaner approaches, and that by using some of the newer features that we've added to IDL and by being a bit more clever we can probably produce a much better architecture. But the market reality is that there are lots and lots of products and lots and lots of existing code that are based on the existing PIDL apis. Do we really think that we can convince our eng managements that they should invest resources to cleaning up the architecture, without significantly enchancing functionality. What will a user be able to do once we've gotten rid of PIDL that they can't do today? (ASide from rewriting and redebugging existing code.) The answer, I submit, is very little. And the consequence, I suggest, is that it will be very difficult to convince companies to implement these kind of changes quickly. This line of argument leads me to the conclusion that an evolutionary approach has much better chance of being successful. I suggest we take the approach of defining (roughly) equivalent (local) IDL to the ORB PIDL (including nvlists and friends) in such a way that: a. It should be relatively easy for a vendor to implement the new stuff as essentially a wrapper on the existing stuff (via delegation). AND b. Both the existing PIDL and new IDL can coexist in the same product/ process/code space. The reality is that no one is going to force their users rewrite working code and that we'll all have to support both approaches for backward compatiblity reasons. At some future point, as people adopt the newer approach, we can start the deprecation process for the existing PIDL. We can help nudge people along, by making it easy for them to migrate. We can also "encourage" the use of the newer stuff by only adding new functionality to it, so that if they want new features, they have to use new stuff. comments? jeff 'Paul Kyzivat' writes: > > > From: butek@us.ibm.com [mailto:butek@us.ibm.com] > > > I guess this is my primary complaint ('worry' is perhaps a > > better word) > > with the IDL ORB approach. There is a lot of work involved > > in defining it. > > Do we have time for that in this FTF? Do we even have > > volunteers for that? > > I just spent a couple of minutes looking at the specific issues for the C++ > language binding. My conclusion is that the issues are much the same whether > we really "idl-ize" the orb interface or create an idl wrapper class. > > The problem is that ORB has a bunch of operations that themselves take PIDL > arguments. The troublesome PIDL things include: Request, NVList, Context. > > So, we have a recursive problem. We can't make IDL versions of the > operations on these things (in either an IDL ORB or an IDL ORB wrapper) > unless we make these real IDL. > > One workaround is to move all of the operations that touch these things to > language specific extensions. > > Building a wrapper that doesn't support any of these, and then forcing use > of the PIDL ORB to use them is another workaround. But this simply leaves us > with a degraded idl interface and no way to deprecate the pidl. > > A third approach would simply be to make all the new interfaces we are > defining PIDL as well, perhaps with instructions that the language mappings > should follow the normal mappings. IMO this is better than the alternatives. > > Paul > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: Paul Kyzivat To: "'Jeffrey Mischkinsky'" , interceptors-ftf@omg.org Subject: RE: Getting rid of ORB PIDL Date: Fri, 24 Mar 2000 14:20:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: F*`d9fKNe9ZYIe94dEe9 I agree with your concerns, and I have a relatively open mind about how to approach a solution. I don't think the voting is especially helpful, because the figure of merit is based on the quality of the finished product, not on the approach used to get there. Having an evolutionary path is one key requirement. Preventing the API from becoming even more arcane (and hopefully making it less so) is another important requirement. What I am afraid of is something like this: CORBA::ORB_var orb = CORBA::ORBinit(argc,argv); CORBA::Object_var obj = orb->resolve_initial_references("NewORB"); CORBA_3_0::ORB_var new_orb = CORBA_3_0::ORB::_narrow(orb); // Now use new_orb instead of orb As long as we can avoid garbage like that the wrapper is ok. We are going to want users to switch to the new way, and they aren't going to see what the point is, so we need to make it easy. Paul > -----Original Message----- > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > Sent: Friday, March 24, 2000 1:11 PM > To: interceptors-ftf@omg.org > Subject: Getting rid of ORB PIDL > > > Hi, > Time for a new thread name. :-) > > I think it would be worth discussing this at a slightly > higher level. > > I have made the argument before that we're kidding ourselves by > believing that we can convince people to throwout the existing > PIDL > infrastructure instantly. As engineers we KNOW that there > are cleaner > approaches, and that by using some of the newer features that > we've > added to IDL and by being a bit more clever we can probably > produce > a much better architecture. > > But the market reality is that there are lots and lots of products > and lots and lots of existing code that are based on the existing > PIDL apis. Do we really think that we can convince our eng > managements > that they should invest resources to cleaning up the architecture, > without significantly enchancing functionality. What will a user > be > able to do once we've gotten rid of PIDL that they can't do today? > (ASide from rewriting and redebugging existing code.) The answer, > I > submit, is very little. And the consequence, I suggest, is that > it will be very difficult to convince companies to implement these > kind of changes quickly. > > This line of argument leads me to the conclusion that an > evolutionary > approach has much better chance of being successful. > > I suggest we take the approach of defining (roughly) > equivalent (local) IDL > to the ORB PIDL (including nvlists and friends) in such a way > that: > a. It should be relatively easy for a vendor to implement > the new stuff > as essentially a wrapper on the existing stuff (via > delegation). > AND > b. Both the existing PIDL and new IDL can coexist in the > same product/ > process/code space. > > The reality is that no one is going to force their users > rewrite working > code and that we'll all have to support both approaches for > backward > compatiblity reasons. > > At some future point, as people adopt the newer approach, > we can start > the deprecation process for the existing PIDL. > > We can help nudge people along, by making it easy for them > to migrate. > We can also "encourage" the use of the newer stuff by only > adding new > functionality to it, so that if they want new features, they have > to > use new stuff. > > comments? > > jeff Date: Fri, 24 Mar 2000 16:04:42 -0330 From: Matthew Newhook To: Paul Kyzivat Cc: "'Jeffrey Mischkinsky'" , interceptors-ftf@omg.org Subject: Re: Getting rid of ORB PIDL Message-ID: <20000324160442.A11335@ooc.com> References: <9B164B713EE9D211B6DC0090273CEEA926BD5B@bos1.noblenet.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre3us In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BD5B@bos1.noblenet.com> Content-Type: text/plain; charset=us-ascii X-UIDL: Ed>!!%B#!!!FJe9ZB>e9 Hi, For what languages is IDL'izing the ORB a problem? For C++ it isn't. I think that Java is an issue since some operations are static on the ORB interface itself... Can anybody comment on some other languages? Regards, Matthew On Fri, Mar 24, 2000 at 02:20:28PM -0500, Paul Kyzivat wrote: > I agree with your concerns, and I have a relatively open mind about > how to > approach a solution. I don't think the voting is especially helpful, > because > the figure of merit is based on the quality of the finished product, > not on > the approach used to get there. > > Having an evolutionary path is one key requirement. > > Preventing the API from becoming even more arcane (and hopefully > making it > less so) is another important requirement. > > What I am afraid of is something like this: > > CORBA::ORB_var orb = CORBA::ORBinit(argc,argv); > CORBA::Object_var obj = > orb->resolve_initial_references("NewORB"); > CORBA_3_0::ORB_var new_orb = > CORBA_3_0::ORB::_narrow(orb); > // Now use new_orb instead of orb > > As long as we can avoid garbage like that the wrapper is ok. > We are going to want users to switch to the new way, and they aren't > going > to see what the point is, so we need to make it easy. > > Paul > > > -----Original Message----- > > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > > Sent: Friday, March 24, 2000 1:11 PM > > To: interceptors-ftf@omg.org > > Subject: Getting rid of ORB PIDL > > > > > > Hi, > > Time for a new thread name. :-) > > > > I think it would be worth discussing this at a slightly > > higher level. > > > > I have made the argument before that we're kidding ourselves by > > believing that we can convince people to throwout the existing > PIDL > > infrastructure instantly. As engineers we KNOW that there > > are cleaner > > approaches, and that by using some of the newer features that > we've > > added to IDL and by being a bit more clever we can probably > produce > > a much better architecture. > > > > But the market reality is that there are lots and lots of > products > > and lots and lots of existing code that are based on the > existing > > PIDL apis. Do we really think that we can convince our eng > > managements > > that they should invest resources to cleaning up the > architecture, > > without significantly enchancing functionality. What will a user > be > > able to do once we've gotten rid of PIDL that they can't do > today? > > (ASide from rewriting and redebugging existing code.) The > answer, I > > submit, is very little. And the consequence, I suggest, is that > > it will be very difficult to convince companies to implement > these > > kind of changes quickly. > > > > This line of argument leads me to the conclusion that an > > evolutionary > > approach has much better chance of being successful. > > > > I suggest we take the approach of defining (roughly) > > equivalent (local) IDL > > to the ORB PIDL (including nvlists and friends) in such a way > that: > > a. It should be relatively easy for a vendor to implement > > the new stuff > > as essentially a wrapper on the existing stuff (via > delegation). > > AND > > b. Both the existing PIDL and new IDL can coexist in the > > same product/ > > process/code space. > > > > The reality is that no one is going to force their users > > rewrite working > > code and that we'll all have to support both approaches for > backward > > compatiblity reasons. > > > > At some future point, as people adopt the newer approach, > > we can start > > the deprecation process for the existing PIDL. > > > > We can help nudge people along, by making it easy for them > > to migrate. > > We can also "encourage" the use of the newer stuff by only > > adding new > > functionality to it, so that if they want new features, they > have to > > use new stuff. > > > > comments? > > > > jeff -- Matthew Newhook E-Mail: mailto:matthew@ooc.com Software Designer WWW: http://www.ooc.com Object Oriented Concepts, Inc. Phone: (709) 738-3725 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