Issue 5579: implementing local interfaces in C++ (cxx_revision) Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com) Nature: Uncategorized Issue Severity: Summary: There seems to be only two choices: 1. Accept that changing interfaces to local breaks old code that implemented POA interfaces using servants. Not wonderful, but I can live with it, since the source code changes are evident and fixed in a straightforward fashion. 2. Try to come up with a scheme where local objects can be implemented either by using LocalObject or by the traditional servant route. This is more specification work, but cleaner, and I an live with it too. While we are at it, we should make sure that any other CORBA 3.0 changes are properly reflected in the C++ mapping as well. Resolution: see proposed resolution for issue #4160 Revised Text: Actions taken: August 9, 2002: rceived issue July 1, 2003: closed issue Discussion: End of Annotations:===== Date: Fri, 09 Aug 2002 15:24:51 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jishnu Mukerji CC: "Normier, Bernhard" , "triodia.com, michi" , Linda Heaton , C++ Revision Task Force , Andrew Watson Subject: Re: C++ revision Jishnu Mukerji wrote: > Bernard, an the rest, > > We should probably start by iguring out what vendors are doing in >the > way of implementing local interfaces in C++ in what tey have > implemented/deployed of CORBA 2.4 and later versions, and use that >as a > starting point. I know the TAO folks have just gone ahead and changed the POA interfaces to use LocalObject, ignoring the backwards compatibility breakage. > I still think that this is an issue that is worthy of being handled as > an urgent one and we should strive to produce a base proposal to get the > ball rolling on it. Meanwile, the original text produced by Steve Vinoki > that was actually adopted should be incorporated into theformal C++ > chapter, since we are on very slippery grounds removing such things > editorially, from a specification. There seems to be only two choices: 1. Accept that changing interfaces to local breaks old code that implemented POA interfaces using servants. Not wonderful, but I can live with it, since the source code changes are evident and fixed in a straightforward fashion. 2. Try to come up with a scheme where local objects can be implemented either by using LocalObject or by the traditional servant route. This is more specification work, but cleaner, and I an live with it too. While we are at it, we should make sure that any other CORBA 3.0 changes are properly reflected in the C++ mapping as well. -- Jon Biggar jon@floorboard.com jon@biggar.org Reply-To: "Michi Henning" From: "Michi Henning" To: "Jonathan Biggar" , "Jishnu Mukerji" Cc: "Normier, Bernhard" , "Linda Heaton" , "C++ Revision Task Force" , "Andrew Watson" Subject: Re: C++ revision Date: Sat, 10 Aug 2002 08:32:12 +1000 Organization: Triodia Technologies X-Mailer: Microsoft Outlook Express 6.00.2600.0000 > > I know the TAO folks have just gone ahead and changed the POA >interfaces to > use LocalObject, ignoring the backwards compatibility breakage. Those guys always were fundamentalists :-) > 1. Accept that changing interfaces to local breaks old code that implemented > POA interfaces using servants. Not wonderful, but I can live with it, since > the source code changes are evident and fixed in a straightforward fashion. > > 2. Try to come up with a scheme where local objects can be implemented either > by using LocalObject or by the traditional servant route. This is more > specification work, but cleaner, and I an live with it too. I would prefer option 1, even though that means some breakage (which, as you say, can be fixed trivially). The C++ mapping is big and complex enough as is, and so are the ORBs... Trying to keep both mappings possible side-by-side would probably turn out rather ugly. Cheers, Michi. Date: Mon, 12 Aug 2002 12:28:13 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: C++ Revision Task Force Cc: Michi Henning , Jonathan Biggar , "Normier, Bernhard" , Linda Heaton , Andrew Watson Subject: Re: C++ revision Michi Henning wrote: > > > > > I know the TAO folks have just gone ahead and changed the POA interfaces > to > > use LocalObject, ignoring the backwards compatibility breakage. > > Those guys always were fundamentalists :-) > > > 1. Accept that changing interfaces to local breaks old code that > implemented > > POA interfaces using servants. Not wonderful, but I can live with it, > since > > the source code changes are evident and fixed in a straightforward > fashion. > > > > 2. Try to come up with a scheme where local objects can be implemented > either > > by using LocalObject or by the traditional servant route. This is more > > specification work, but cleaner, and I an live with it too. > > I would prefer option 1, even though that means some breakage (which, as > you say, can be fixed trivially). The C++ mapping is big and complex enough > as is, and so are the ORBs... Trying to keep both mappings possible > side-by-side would probably turn out rather ugly. I guess the bottom line is, no matter what we want to do with Issue 4172, 4186 and 4545, wefirst need to figure out where the adopted text penned by Steve Vinoski needs to be restored in the C++ mapping spec. Then we need to figure out what fixes need to be made to it, and make that happen very quickly. I don't think Choice 2 above can be done quickly, if ever.:-) So IMHO we should concentrate on making sure that the specification works as per choice 1. Andrew Watson said: > I agree - we can't hack out normative text as an editorial change. To get > it done quickly, we'd have to declare it urgent. > > At the moment the C++ RTF has just three members: > > Floorboard Software Jon Biggar > Hewlett-Packard Jishnu Mukerji > IONA Bernard Normier (CHAIR) > > However, the mailing list has 61 names, some of which are company > exploders. If we're going to resolve this as an urgent issue, we should at > least get opinions from other C++ ORB providers as well, including: > > 2AB > Vertel > Borland > Objective Interface Systems > Fujitsu > Prism Technology > OCI > IBM > MICO > > ... and others that I've forgotten. > > However, arguably anyone who didn't put themselves on the RTF has only > themselves to blame if it comes up with a solution they don't like :-). > BTW, what was the text that Linda sent you Michi about the C++ mapping of Local Objects? I was wondering if that was the last final version that Steve put together. I am not even sure whether the last final version that Steve put together was actually recommended by the FTF. So what might need to happen is that the text adopted by the pre-FTF adoption process needs to be inserted and perhaps the last final version with the create_ref stuff needs to be addressed as resolution to issue 4172 or some such, in an urgent manner. Sigh..... Jishnu. Subject: RE: C++ revision Date: Mon, 12 Aug 2002 23:58:17 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: C++ revision Thread-Index: AcJCIBnxsx/sx41pT42qsPahRQ5AOAAXQ1Rg From: "Vinoski, Stephen" To: "Jishnu Mukerji" , "C++ Revision Task Force" Cc: "triodia.com, michi" , "Jonathan Biggar" , "Normier, Bernhard" , "Linda Heaton" , "Andrew Watson" X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id g7D3swX12132 The last version of a C++ mapping for LocalObject that I put together was not accepted, I believe by you, Jishnu, if my memory serves correctly. i think I remember that the last version added factory operations as designed by Jon, but I believe your response was that some deadline had passed and further changes could not be accepted at the time. Unfortunately I have lost all track of that whole conversation, and my proposals, as that all occurred years ago and I have switched laptops and email programs several times in the interim. --steve > -----Original Message----- > From: Jishnu Mukerji [mailto:jishnu_mukerji@hp.com] > Sent: Monday, August 12, 2002 12:28 PM > To: C++ Revision Task Force > Cc: triodia.com, michi; Jonathan Biggar; Normier, Bernhard; Linda > Heaton; Andrew Watson > Subject: Re: C++ revision > > > > > Michi Henning wrote: > > > > > > > > I know the TAO folks have just gone ahead and changed the > POA interfaces > > to > > > use LocalObject, ignoring the backwards compatibility breakage. > > > > Those guys always were fundamentalists :-) > > > > > 1. Accept that changing interfaces to local breaks old code that > > implemented > > > POA interfaces using servants. Not wonderful, but I can > live with it, > > since > > > the source code changes are evident and fixed in a straightforward > > fashion. > > > > > > 2. Try to come up with a scheme where local objects can > be implemented > > either > > > by using LocalObject or by the traditional servant route. > This is more > > > specification work, but cleaner, and I an live with it too. > > > > I would prefer option 1, even though that means some > breakage (which, as > > you say, can be fixed trivially). The C++ mapping is big > and complex enough > > as is, and so are the ORBs... Trying to keep both mappings possible > > side-by-side would probably turn out rather ugly. > > I guess the bottom line is, no matter what we want to do with Issue > 4172, 4186 and 4545, wefirst need to figure out where the adopted text > penned by Steve Vinoski needs to be restored in the C++ mapping spec. > > Then we need to figure out what fixes need to be made to it, and make > that happen very quickly. > > I don't think Choice 2 above can be done quickly, if ever.:-) > So IMHO we > should concentrate on making sure that the specification works as per > choice 1. > > Andrew Watson said: > > I agree - we can't hack out normative text as an editorial > change. To get > > it done quickly, we'd have to declare it urgent. > > > > At the moment the C++ RTF has just three members: > > > > Floorboard Software Jon Biggar > > Hewlett-Packard Jishnu Mukerji > > IONA Bernard Normier (CHAIR) > > > > However, the mailing list has 61 names, some of which are company > > exploders. If we're going to resolve this as an urgent > issue, we should at > > least get opinions from other C++ ORB providers as well, including: > > > > 2AB > > Vertel > > Borland > > Objective Interface Systems > > Fujitsu > > Prism Technology > > OCI > > IBM > > MICO > > > > ... and others that I've forgotten. > > > > However, arguably anyone who didn't put themselves on the > RTF has only > > themselves to blame if it comes up with a solution they > don't like :-). > > > > > BTW, what was the text that Linda sent you Michi about the C++ mapping > of Local Objects? I was wondering if that was the last final version > that Steve put together. I am not even sure whether the last final > version that Steve put together was actually recommended by > the FTF. So > what might need to happen is that the text adopted by the pre-FTF > adoption process needs to be inserted and perhaps the last > final version > with the create_ref stuff needs to be addressed as resolution to issue > 4172 or some such, in an urgent manner. > > Sigh..... > > Jishnu. > X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 13 Aug 2002 09:34:44 -0400 To: Jonathan Biggar From: Bill Beckwith Subject: Re: C++ revision Cc: Jishnu Mukerji , "Normier, Bernhard" , "triodia.com, michi" , Linda Heaton , C++ Revision Task Force , Andrew Watson At 06:24 PM 8/9/2002, Jonathan Biggar wrote: >Jishnu Mukerji wrote: > >> I still think that this is an issue that is worthy of being handled as >> an urgent one and we should strive to produce a base proposal to get the >> ball rolling on it. Meanwile, the original text produced by Steve Vinoki >> that was actually adopted should be incorporated into theformal C++ >> chapter, since we are on very slippery grounds removing such things >> editorially, from a specification. I agree that a clean, efficient LocalObject mapping needs to be added to the specification. I do not agree that we should handle this as an urgent issue. We have had LocalObject support in our shipping products for more than a year now. I am very concerned about making hasty changes to the C++ mapping that will damage forward compatibility customer applications. >There seems to be only two choices: > >1. Accept that changing interfaces to local breaks old code that >implemented >POA interfaces using servants. Not wonderful, but I can live with >it, since >the source code changes are evident and fixed in a straightforward >fashion. I think I agree with this approach. It sounds like you are protecting the forward compatibility of the ORB implementation itself not the applications built with the ORB. Right? I am mostly concerned about the forward compatibility of CORBA applications. WRT to the ORB compatibility, we have implemented a very lightweight approach to implementing LocalObject. If our consensus result achieves this objective I'm happy to invest in infrastructure changes. >2. Try to come up with a scheme where local objects can be implemented either >by using LocalObject or by the traditional servant route. This is more >specification work, but cleaner, and I an live with it too. > >While we are at it, we should make sure that any other CORBA 3.0 changes are >properly reflected in the C++ mapping as well. I completely agree that we should clean up the mapping for CORBA 3.0. Again, let's use caution with declaring issues urgent. Bill Date: Tue, 13 Aug 2002 09:53:33 -0500 From: Paul Calabrese Reply-To: calabrese_p@ociweb.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en To: Andrew Watson CC: Jishnu Mukerji , Michi Henning , Linda Heaton , C++ Revision Task Force Subject: Re: C++ revision Andrew Watson wrote: However, the mailing list has 61 names, some of which are company exploders. If we're going to resolve this as an urgent issue, we should at least get opinions from other C++ ORB providers as well, including: 2AB Vertel Borland Objective Interface Systems Fujitsu Prism Technology OCI IBM MICO I'll take this opportunity to jump out of "lurker" mode because this is something of current interest to me. I have been trying to write a short paper about local interfaces and objects and have been wading through some of this history and details of TAO's implementation. TAO implements local objects with the following characteristics: - CORBA::LocalObject does not implement reference counting, by default - TAO includes a TAO_Local_RefCounted_Object class that is derived from CORBA::LocalObject and does include reference counting - No function is provided for conversion to _ptr types (Applications depend on the fact that in TAO _ptr types are really pointers and implicit casts do the job) - Servant Managers are implemented as true local objects (in a manner that is not backward compatible with existing applications) I understand that some of this may need to be changed when the mapping is finalized. Here are some specific questions: 1) Is reference counting going to be enabled, by default, in CORBA::LocalObject? If not I would think you should include a standard reference counted local object class in the mapping. 2) Is the LI::create_reference() static member function going to be included? What is its signature? I assume something like: class LI : public virtual CORBA_Object { public: static LI_ptr create_reference(LI*); but I started to wonder whether we needed an ORB_ptr in there as an argument. Do local objects (and their references) need to be associated with an ORB? 3) Do you need to do an ORB_init() to create and use local objects? Interestingly enough TAO works fine without an ORB_init(). 4) It sounds like the general consensus to treat servant managers as normal local objects and break the existing code. Has this been definitively decided? -- Paul Calabrese Object Computing Inc. (314) 579-0066 Date: Tue, 13 Aug 2002 11:40:27 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: "Vinoski, Stephen" Cc: C++ Revision Task Force , "triodia.com, michi" , Jonathan Biggar , "Normier, Bernhard" , Linda Heaton , Andrew Watson Subject: Re: C++ revision Steve, Thanks, I remember now. I do have that version with me. I think what we should do is run it through the urgent process in the C++ RTF so that it can get into both 2.6 and 3.0 more or less as is. This proposed resolution could be enhanced to address the issue raised in Issue 4172, if that is deemed important. Else we could simply use Issue 4545 to do the urgent resolution. Until we do that, the adopted version, which is missing the factory operations should be in all C++ mapping chapters that came out after CORBA 2.4 (I believe). So Linda, which version of the C++ mapping of Local objects text did you have? So Yes, I do have both proposals, the adopted one and the Vinoski act II one. Any thoughts on how we should proceed Mr. Chair (that would be Bernard I presume)? Jishnu. "Vinoski, Stephen" wrote: > > The last version of a C++ mapping for LocalObject that I put together was not accepted, I believe by you, Jishnu, if my memory serves correctly. i think I remember that the last version added factory operations as designed by Jon, but I believe your response was that some deadline had passed and further changes could not be accepted at the time. Unfortunately I have lost all track of that whole conversation, and my proposals, as that all occurred years ago and I have switched laptops and email programs several times in the interim. > > --steve > > > -----Original Message----- > > From: Jishnu Mukerji [mailto:jishnu_mukerji@hp.com] > > Sent: Monday, August 12, 2002 12:28 PM > > To: C++ Revision Task Force > > Cc: triodia.com, michi; Jonathan Biggar; Normier, Bernhard; Linda > > Heaton; Andrew Watson > > Subject: Re: C++ revision > > > > > > > > > > Michi Henning wrote: > > > > > > > > > > > I know the TAO folks have just gone ahead and changed the > > POA interfaces > > > to > > > > use LocalObject, ignoring the backwards compatibility breakage. > > > > > > Those guys always were fundamentalists :-) > > > > > > > 1. Accept that changing interfaces to local breaks old code that > > > implemented > > > > POA interfaces using servants. Not wonderful, but I can > > live with it, > > > since > > > > the source code changes are evident and fixed in a straightforward > > > fashion. > > > > > > > > 2. Try to come up with a scheme where local objects can > > be implemented > > > either > > > > by using LocalObject or by the traditional servant route. > > This is more > > > > specification work, but cleaner, and I an live with it too. > > > > > > I would prefer option 1, even though that means some > > breakage (which, as > > > you say, can be fixed trivially). The C++ mapping is big > > and complex enough > > > as is, and so are the ORBs... Trying to keep both mappings possible > > > side-by-side would probably turn out rather ugly. > > > > I guess the bottom line is, no matter what we want to do with Issue > > 4172, 4186 and 4545, wefirst need to figure out where the adopted text > > penned by Steve Vinoski needs to be restored in the C++ mapping spec. > > > > Then we need to figure out what fixes need to be made to it, and make > > that happen very quickly. > > > > I don't think Choice 2 above can be done quickly, if ever.:-) > > So IMHO we > > should concentrate on making sure that the specification works as per > > choice 1. > > > > Andrew Watson said: > > > I agree - we can't hack out normative text as an editorial > > change. To get > > > it done quickly, we'd have to declare it urgent. > > > > > > At the moment the C++ RTF has just three members: > > > > > > Floorboard Software Jon Biggar > > > Hewlett-Packard Jishnu Mukerji > > > IONA Bernard Normier (CHAIR) > > > > > > However, the mailing list has 61 names, some of which are company > > > exploders. If we're going to resolve this as an urgent > > issue, we should at > > > least get opinions from other C++ ORB providers as well, including: > > > > > > 2AB > > > Vertel > > > Borland > > > Objective Interface Systems > > > Fujitsu > > > Prism Technology > > > OCI > > > IBM > > > MICO > > > > > > ... and others that I've forgotten. > > > > > > However, arguably anyone who didn't put themselves on the > > RTF has only > > > themselves to blame if it comes up with a solution they > > don't like :-). > > > > > > > > > BTW, what was the text that Linda sent you Michi about the C++ mapping > > of Local Objects? I was wondering if that was the last final version > > that Steve put together. I am not even sure whether the last final > > version that Steve put together was actually recommended by > > the FTF. So > > what might need to happen is that the text adopted by the pre-FTF > > adoption process needs to be inserted and perhaps the last > > final version > > with the create_ref stuff needs to be addressed as resolution to issue > > 4172 or some such, in an urgent manner. > > > > Sigh..... > > > > Jishnu. > > -- Jishnu Mukerji Senior Systems Architect, SGBU Staff Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA tel:+1 973 443 7528 mailto:jishnu_mukerji@hp.com Subject: RE: C++ revision Date: Tue, 13 Aug 2002 11:45:32 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: C++ revision Thread-Index: AcJC38UTqVI9GxYoT0iDXcqueWNebAAAFyMA From: "Normier, Bernhard" To: "Jishnu Mukerji" , "Vinoski, Stephen" Cc: "C++ Revision Task Force" , "triodia.com, michi" , "Jonathan Biggar" , "Linda Heaton" , "Andrew Watson" X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id g7DFg6X23139 As a first step, I'd like to get all the existing proposals (or somewhat hidden adopted text) visible to everybody. If you know any, could you either send the OMG doc number or the entire document to this mailing list? Thanks, Bernard > -----Original Message----- > From: Jishnu Mukerji [mailto:jishnu_mukerji@hp.com] > Sent: Tuesday, August 13, 2002 11:40 AM > To: Vinoski, Stephen > Cc: C++ Revision Task Force; triodia.com, michi; Jonathan Biggar; > Normier, Bernhard; Linda Heaton; Andrew Watson > Subject: Re: C++ revision > > > Steve, > > Thanks, I remember now. I do have that version with me. I > think what we > should do is run it through the urgent process in the C++ RTF > so that it > can get into both 2.6 and 3.0 more or less as is. This proposed > resolution could be enhanced to address the issue raised in > Issue 4172, > if that is deemed important. Else we could simply use Issue 4545 to do > the urgent resolution. > > Until we do that, the adopted version, which is missing the factory > operations should be in all C++ mapping chapters that came out after > CORBA 2.4 (I believe). So Linda, which version of the C++ mapping of > Local objects text did you have? > > So Yes, I do have both proposals, the adopted one and the > Vinoski act II > one. > > Any thoughts on how we should proceed Mr. Chair (that would > be Bernard I > presume)? > > Jishnu. > > "Vinoski, Stephen" wrote: > > > > The last version of a C++ mapping for LocalObject that I > put together was not accepted, I believe by you, Jishnu, if > my memory serves correctly. i think I remember that the last > version added factory operations as designed by Jon, but I > believe your response was that some deadline had passed and > further changes could not be accepted at the time. > Unfortunately I have lost all track of that whole > conversation, and my proposals, as that all occurred years > ago and I have switched laptops and email programs several > times in the interim. > > > > --steve > > > > > -----Original Message----- > > > From: Jishnu Mukerji [mailto:jishnu_mukerji@hp.com] > > > Sent: Monday, August 12, 2002 12:28 PM > > > To: C++ Revision Task Force > > > Cc: triodia.com, michi; Jonathan Biggar; Normier, Bernhard; Linda > > > Heaton; Andrew Watson > > > Subject: Re: C++ revision > > > > > > > > > > > > > > > Michi Henning wrote: > > > > > > > > > > > > > > I know the TAO folks have just gone ahead and changed the > > > POA interfaces > > > > to > > > > > use LocalObject, ignoring the backwards compatibility > breakage. > > > > > > > > Those guys always were fundamentalists :-) > > > > > > > > > 1. Accept that changing interfaces to local breaks > old code that > > > > implemented > > > > > POA interfaces using servants. Not wonderful, but I can > > > live with it, > > > > since > > > > > the source code changes are evident and fixed in a > straightforward > > > > fashion. > > > > > > > > > > 2. Try to come up with a scheme where local objects can > > > be implemented > > > > either > > > > > by using LocalObject or by the traditional servant route. > > > This is more > > > > > specification work, but cleaner, and I an live with it too. > > > > > > > > I would prefer option 1, even though that means some > > > breakage (which, as > > > > you say, can be fixed trivially). The C++ mapping is big > > > and complex enough > > > > as is, and so are the ORBs... Trying to keep both > mappings possible > > > > side-by-side would probably turn out rather ugly. > > > > > > I guess the bottom line is, no matter what we want to do > with Issue > > > 4172, 4186 and 4545, wefirst need to figure out where the > adopted text > > > penned by Steve Vinoski needs to be restored in the C++ > mapping spec. > > > > > > Then we need to figure out what fixes need to be made to > it, and make > > > that happen very quickly. > > > > > > I don't think Choice 2 above can be done quickly, if ever.:-) > > > So IMHO we > > > should concentrate on making sure that the specification > works as per > > > choice 1. > > > > > > Andrew Watson said: > > > > I agree - we can't hack out normative text as an editorial > > > change. To get > > > > it done quickly, we'd have to declare it urgent. > > > > > > > > At the moment the C++ RTF has just three members: > > > > > > > > Floorboard Software Jon Biggar > > > > Hewlett-Packard Jishnu Mukerji > > > > IONA Bernard Normier (CHAIR) > > > > > > > > However, the mailing list has 61 names, some of which > are company > > > > exploders. If we're going to resolve this as an urgent > > > issue, we should at > > > > least get opinions from other C++ ORB providers as > well, including: > > > > > > > > 2AB > > > > Vertel > > > > Borland > > > > Objective Interface Systems > > > > Fujitsu > > > > Prism Technology > > > > OCI > > > > IBM > > > > MICO > > > > > > > > ... and others that I've forgotten. > > > > > > > > However, arguably anyone who didn't put themselves on the > > > RTF has only > > > > themselves to blame if it comes up with a solution they > > > don't like :-). > > > > > > > > > > > > > BTW, what was the text that Linda sent you Michi about > the C++ mapping > > > of Local Objects? I was wondering if that was the last > final version > > > that Steve put together. I am not even sure whether the last final > > > version that Steve put together was actually recommended by > > > the FTF. So > > > what might need to happen is that the text adopted by the pre-FTF > > > adoption process needs to be inserted and perhaps the last > > > final version > > > with the create_ref stuff needs to be addressed as > resolution to issue > > > 4172 or some such, in an urgent manner. > > > > > > Sigh..... > > > > > > Jishnu. > > > > > -- > Jishnu Mukerji > Senior Systems Architect, SGBU Staff > Hewlett-Packard Company > 300 Campus Drive, MS 2E-62 > Florham Park NJ 07932, USA > tel:+1 973 443 7528 > mailto:jishnu_mukerji@hp.com > Date: Tue, 13 Aug 2002 12:19:25 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: "Normier, Bernhard" Cc: "Vinoski, Stephen" , C++ Revision Task Force , "triodia.com, michi" , Jonathan Biggar , Linda Heaton , Andrew Watson Subject: Re: C++ revision OK, here goes, after much struggle with Acrobat Distiller...... The file "LocalObjectC++MappingAsAdopted.pdf" attached below contains the text that was actually adopted. The file "LocalObjectC++MappingEnhanced.pdf" attached below contains the text that Steve produced when the adoption vote had already completed, and hence never did really go through any adoption process. Hope this helps. Jishnu "Normier, Bernhard" wrote: > > As a first step, I'd like to get all the existing proposals > (or somewhat hidden adopted text) visible to everybody. > > If you know any, could you either send the OMG doc number or > the entire document to this mailing list? > > Thanks, > > Bernard LocalObjectC++MappingAsAdopted.pdf LocalObjectC++MappingEnhanced.pdf Date: Tue, 13 Aug 2002 12:30:14 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Bill Beckwith Cc: Jonathan Biggar , "Normier, Bernhard" , "triodia.com, michi" , Linda Heaton , C++ Revision Task Force , Andrew Watson Subject: Re: C++ revision Bill Beckwith wrote: > > At 06:24 PM 8/9/2002, Jonathan Biggar wrote: > >Jishnu Mukerji wrote: > > > >> I still think that this is an issue that is worthy of being handled as > >> an urgent one and we should strive to produce a base proposal to get the > >> ball rolling on it. Meanwile, the original text produced by Steve Vinoki > >> that was actually adopted should be incorporated into theformal C++ > >> chapter, since we are on very slippery grounds removing such things > >> editorially, from a specification. > > I agree that a clean, efficient LocalObject mapping needs to > be added to the specification. I do not agree that we should > handle this as an urgent issue. There actually is an adopted incomplete specification that is missing from the Chapter which first needs to be restored, since it is an adopted piece of text. See separate message from me for what the adopted text is. Beyond that, it should be upto those with deployed C++ products to decide whether it is urgently fixed to be more complete or not. At the end of the day, since portability from one C++ ORB to another is perhaps more or less a non-issue given the grodiness of C++ itself. Perhaps we could simply leave things as per the adopted text and let people do whatever. My problem with that is it cause API level breakage, i.e. app writers cannot depend on the existence of some basic APIs in a uniform way, => breakage at the app source level. However, those with C++ products are much better situated to decide whether that is an issue worthy of consideration and hence requiring an urgent resolution for this issue or not, than I. > We have had LocalObject support in our shipping products for > more than a year now. I am very concerned about making hasty > changes to the C++ mapping that will damage forward compatibility > customer applications. What is the meaning of forward compatibility as used above? I guess I am genuinely confused and want to understand. Thanks, X-Sender: linda@emerald.omg.org X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Aug 2002 12:44:34 -0400 To: Jishnu Mukerji , "Vinoski, Stephen" From: Linda Heaton Subject: Re: C++ revision Cc: C++ Revision Task Force , "triodia.com, michi" , Jonathan Biggar , "Normier, Bernhard" , Andrew Watson At 11:40 AM 8/13/02 -0400, Jishnu Mukerji wrote: Steve, Thanks, I remember now. I do have that version with me. I think what we should do is run it through the urgent process in the C++ RTF so that it can get into both 2.6 and 3.0 more or less as is. This proposed resolution could be enhanced to address the issue raised in Issue 4172, if that is deemed important. Else we could simply use Issue 4545 to do the urgent resolution. Until we do that, the adopted version, which is missing the factory operations should be in all C++ mapping chapters that came out after CORBA 2.4 (I believe). So Linda, which version of the C++ mapping of Local objects text did you have? Folks, The text that appears in ptc/99-10-09 (a CCM draft document) but not in ptc/01-06-07 (C++ convenience document) is the same text that is in the PDF file named LocalObjectC++MappingAsAdopted (without the final Note). /Linda So Yes, I do have both proposals, the adopted one and the Vinoski act II one. Any thoughts on how we should proceed Mr. Chair (that would be Bernard I presume)? Jishnu. "Vinoski, Stephen" wrote: > > The last version of a C++ mapping for LocalObject that I put together was not accepted, I believe by you, Jishnu, if my memory serves correctly. i think I remember that the last version added factory operations as designed by Jon, but I believe your response was that some deadline had passed and further changes could not be accepted at the time. Unfortunately I have lost all track of that whole conversation, and my proposals, as that all occurred years ago and I have switched laptops and email programs several times in the interim. > > --steve > > > -----Original Message----- > > From: Jishnu Mukerji [mailto:jishnu_mukerji@hp.com] > > Sent: Monday, August 12, 2002 12:28 PM > > To: C++ Revision Task Force > > Cc: triodia.com, michi; Jonathan Biggar; Normier, Bernhard; Linda > > Heaton; Andrew Watson > > Subject: Re: C++ revision > > > > > > > > > > Michi Henning wrote: > > > > > > > > > > > I know the TAO folks have just gone ahead and changed the > > POA interfaces > > > to > > > > use LocalObject, ignoring the backwards compatibility breakage. > > > > > > Those guys always were fundamentalists :-) > > > > > > > 1. Accept that changing interfaces to local breaks old code that > > > implemented > > > > POA interfaces using servants. Not wonderful, but I can > > live with it, > > > since > > > > the source code changes are evident and fixed in a straightforward > > > fashion. > > > > > > > > 2. Try to come up with a scheme where local objects can > > be implemented > > > either > > > > by using LocalObject or by the traditional servant route. > > This is more > > > > specification work, but cleaner, and I an live with it too. > > > > > > I would prefer option 1, even though that means some > > breakage (which, as > > > you say, can be fixed trivially). The C++ mapping is big > > and complex enough > > > as is, and so are the ORBs... Trying to keep both mappings possible > > > side-by-side would probably turn out rather ugly. > > > > I guess the bottom line is, no matter what we want to do with Issue > > 4172, 4186 and 4545, wefirst need to figure out where the adopted text > > penned by Steve Vinoski needs to be restored in the C++ mapping spec. > > > > Then we need to figure out what fixes need to be made to it, and make > > that happen very quickly. > > > > I don't think Choice 2 above can be done quickly, if ever.:-) > > So IMHO we > > should concentrate on making sure that the specification works as per > > choice 1. > > > > Andrew Watson said: > > > I agree - we can't hack out normative text as an editorial > > change. To get > > > it done quickly, we'd have to declare it urgent. > > > > > > At the moment the C++ RTF has just three members: > > > > > > Floorboard Software Jon Biggar > > > Hewlett-Packard Jishnu Mukerji > > > IONA Bernard Normier (CHAIR) > > > > > > However, the mailing list has 61 names, some of which are company > > > exploders. If we're going to resolve this as an urgent > > issue, we should at > > > least get opinions from other C++ ORB providers as well, including: > > > > > > 2AB > > > Vertel > > > Borland > > > Objective Interface Systems > > > Fujitsu > > > Prism Technology > > > OCI > > > IBM > > > MICO > > > > > > ... and others that I've forgotten. > > > > > > However, arguably anyone who didn't put themselves on the > > RTF has only > > > themselves to blame if it comes up with a solution they > > don't like :-). > > > > > > > > > BTW, what was the text that Linda sent you Michi about the C++ mapping > > of Local Objects? I was wondering if that was the last final version > > that Steve put together. I am not even sure whether the last final > > version that Steve put together was actually recommended by > > the FTF. So > > what might need to happen is that the text adopted by the pre-FTF > > adoption process needs to be inserted and perhaps the last > > final version > > with the create_ref stuff needs to be addressed as resolution to issue > > 4172 or some such, in an urgent manner. > > > > Sigh..... > > > > Jishnu. > > -- Jishnu Mukerji Senior Systems Architect, SGBU Staff Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA tel:+1 973 443 7528 mailto:jishnu_mukerji@hp.com Subject: RE: C++ revision Date: Tue, 13 Aug 2002 18:47:54 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: C++ revision Thread-Index: AcJC2Y84W2ySGEDUToSEIBYWFTByRgAP5cog From: "Normier, Bernhard" To: , "Andrew Watson" Cc: "Jishnu Mukerji" , "triodia.com, michi" , "Linda Heaton" , "C++ Revision Task Force" X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id g7DMieX08504 Hi Paul, Here is what Orbix 2000 (aka ASP) does: > TAO implements local objects with the following characteristics: > - CORBA::LocalObject does not implement reference counting, > by default Same in Orbix 2000. > - TAO includes a TAO_Local_RefCounted_Object class that is > derived from CORBA::LocalObject and does include reference > counting It's called IT_CORBA::RefCountedLocalObject in Orbix 2000. > - No function is provided for conversion to _ptr types > (Applications depend on the fact that in TAO _ptr types > are really pointers and implicit casts do the job) Same in Orbix 2000. > - Servant Managers are implemented as true local objects > (in a manner that is not backward compatible with > existing applications) Same in Orbix 2000. > I understand that some of this may need to be changed when > the mapping is finalized. Here are some specific questions: > > 1) Is reference counting going to be enabled, by default, > in CORBA::LocalObject? If not I would think you should > include a standard reference counted local object class > in the mapping. Having ref-counting by default would be consistent with the latest C++ PortableServer::ServantBase; no ref-counting by default would match TAO's and Orbix 2000's current implementation. > > 2) Is the LI::create_reference() static member function > going to be included? What is its signature? I assume > something like: > > class LI : public virtual CORBA_Object { > public: > static LI_ptr create_reference(LI*); > > but I started to wonder whether we needed an ORB_ptr in > there as an argument. Do local objects (and their references) > need to be associated with an ORB? I don't see any reason to force an association with an ORB. Maybe we could specify that there is an implicit conversion * to _ptr, and avoid this extra call? > > 3) Do you need to do an ORB_init() to create and use local objects? > Interestingly enough TAO works fine without an ORB_init(). Same with Orbix 2000. I don't think any ORB association should be mandated. > > 4) It sounds like the general consensus to treat servant managers > as normal local objects and break the existing code. Has this > been definitively decided? No vote has taken place yet, so nothing is decided. Cheers, Bernard Sender: jbiggar@Resonate.com Date: Tue, 13 Aug 2002 16:05:49 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: "Normier, Bernhard" CC: calabrese_p@ociweb.com, Andrew Watson , Jishnu Mukerji , "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Subject: Re: C++ revision "Normier, Bernhard" wrote: > Here is what Orbix 2000 (aka ASP) does: > > - TAO includes a TAO_Local_RefCounted_Object class that is > > derived from CORBA::LocalObject and does include reference > > counting > > It's called IT_CORBA::RefCountedLocalObject in Orbix 2000. I think it is critical that this class be standardized in the mapping. Otherwise it becomes a wee bit difficult to write portable code and still guarantee thread safety. > > I understand that some of this may need to be changed when > > the mapping is finalized. Here are some specific questions: > > > > 1) Is reference counting going to be enabled, by default, > > in CORBA::LocalObject? If not I would think you should > > include a standard reference counted local object class > > in the mapping. > > Having ref-counting by default would be consistent with the > latest C++ PortableServer::ServantBase; no ref-counting by > default would match TAO's and Orbix 2000's current implementation. I'd prefer that LocalObject do the reference counting automatically. I can't think of a scenario where not reference counting, or using a custom reference counting scheme is the right thing to do. > > 2) Is the LI::create_reference() static member function > > going to be included? What is its signature? I assume > > something like: > > > > class LI : public virtual CORBA_Object { > > public: > > static LI_ptr create_reference(LI*); > > > > but I started to wonder whether we needed an ORB_ptr in > > there as an argument. Do local objects (and their references) > > need to be associated with an ORB? > > I don't see any reason to force an association with an ORB. In fact, we can't, since local objects are used in Portable Interceptors which must be created before an ORB_ptr exists. > Maybe we could specify that there is an implicit conversion > * to _ptr, and avoid this extra > call? That might work. > > > > 3) Do you need to do an ORB_init() to create and use local objects? > > Interestingly enough TAO works fine without an ORB_init(). > > Same with Orbix 2000. I don't think any ORB association should be > mandated. See above, we must not require ORB_init() first, otherwise PI breaks. > > 4) It sounds like the general consensus to treat servant managers > > as normal local objects and break the existing code. Has this > > been definitively decided? > > No vote has taken place yet, so nothing is decided. Seems to be the unofficial consensus of the members of the RTF. :) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 13 Aug 2002 19:27:36 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: "Normier, Bernhard" , calabrese_p@ociweb.com, Andrew Watson , "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Subject: Re: C++ revision Jonathan Biggar wrote: > > "Normier, Bernhard" wrote: > > > 4) It sounds like the general consensus to treat servant managers > > > as normal local objects and break the existing code. Has this > > > been definitively decided? > > > > No vote has taken place yet, so nothing is decided. Well nothing has been decided about where to go from here. But the here where we are is where servent managers are normal local objects that break existing code as per the adopted spec. The RTF could decide to make a change in the adopted specification so as to make it not break existing code, but so far the email discussion that has happened seems to indicate that very few have the stomach to figure out what that non-code-breaking alternative is. Personally, I would like to see this situation of underspecification resolved soon, rather than us all sitting around and contemplating our navels and how many angels can dance on the head of a C++ pin for the next 6 months.:-) I would also prefer that whetever was decided is plugged into a dot dot release of CORBA 2.6 and later releases of CORBA. We at HP need a stable mapping for this before we put this in the HP Nonstop Server. Jishnu. Sender: jbiggar@Resonate.com Date: Tue, 13 Aug 2002 17:10:21 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: "Normier, Bernhard" , calabrese_p@ociweb.com, Andrew Watson , "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Subject: Re: C++ revision Jishnu Mukerji wrote: > Personally, I would like to see this situation of underspecification > resolved soon, rather than us all sitting around and contemplating our > navels and how many angels can dance on the head of a C++ pin for the > next 6 months.:-) I would also prefer that whetever was decided is > plugged into a dot dot release of CORBA 2.6 and later releases of CORBA. > We at HP need a stable mapping for this before we put this in the HP > Nonstop Server. The only thing in CORBA 2.6.1 that this issue affects is the example C++ code in chapter 11, right? Otherwise, there's been no formal published C++ mapping since 1999. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 14 Aug 2002 10:54:29 -0400 From: "Manfred R. Koethe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us To: Jishnu Mukerji CC: "triodia.com, michi" , C++ Revision Task Force Subject: Re: C++ revision X-Loop-Detect: 1 Hi, As a C++ USER (and silent C++ RTF observer), I would MUCH more prefere a clean break at a well-known version compared to a creaping evolution with vastly unknown side-effects. Thanks, Manfred Jishnu Mukerji wrote: Jonathan Biggar wrote: "Normier, Bernhard" wrote: 4) It sounds like the general consensus to treat servant managers as normal local objects and break the existing code. Has this been definitively decided? No vote has taken place yet, so nothing is decided. Well nothing has been decided about where to go from here. But the here where we are is where servent managers are normal local objects that break existing code as per the adopted spec. The RTF could decide to make a change in the adopted specification so as to make it not break existing code, but so far the email discussion that has happened seems to indicate that very few have the stomach to figure out what that non-code-breaking alternative is. Personally, I would like to see this situation of underspecification resolved soon, rather than us all sitting around and contemplating our navels and how many angels can dance on the head of a C++ pin for the next 6 months.:-) I would also prefer that whetever was decided is plugged into a dot dot release of CORBA 2.6 and later releases of CORBA. We at HP need a stable mapping for this before we put this in the HP Nonstop Server. Jishnu. -- ___________________ / Manfred R. Koethe \_____________________________________ 88solutions Corp. E-Mail: koethe@88solutions.com 37 Mague Avenue Tel: +1 (617) 916 5886 Newton, MA 02465-1553 FAX: +1 (617) 916 5887 U.S.A. _____________________________"We make your business flow"_ X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 14 Aug 2002 16:37:59 -0400 To: "Normier, Bernhard" From: Bill Beckwith Subject: RE: C++ revision Cc: , "Andrew Watson" , "Jishnu Mukerji" , "triodia.com, michi" , "Linda Heaton" , "C++ Revision Task Force" I thought I'd chime in with answers for ORBexpress: >> TAO implements local objects with the following characteristics: >> - CORBA::LocalObject does not implement reference counting, >> by default > >Same in Orbix 2000. ORBexpress reference counts LocalObject's by default. This makes sense since servants are now reference counted by default. To reiterate a bit of the old servant RC debate, it never hurts to include the reference counting. It doesn't prevent the user from using release to remove a reference to the LocalObject. >> - TAO includes a TAO_Local_RefCounted_Object class that is >> derived from CORBA::LocalObject and does include reference >> counting > >It's called IT_CORBA::RefCountedLocalObject in Orbix 2000. There is not need for a class like this in ORBexpress. >> - No function is provided for conversion to _ptr types >> (Applications depend on the fact that in TAO _ptr types >> are really pointers and implicit casts do the job) > >Same in Orbix 2000. Same in ORBexpress. >> - Servant Managers are implemented as true local objects >> (in a manner that is not backward compatible with >> existing applications) > >Same in Orbix 2000. ORBexpress does not currently include this change to ServantManager, but we anticipate making this change in a subsequent release. >> I understand that some of this may need to be changed when >> the mapping is finalized. Here are some specific questions: >> >> 1) Is reference counting going to be enabled, by default, >> in CORBA::LocalObject? If not I would think you should >> include a standard reference counted local object class >> in the mapping. > >Having ref-counting by default would be consistent with the >latest C++ PortableServer::ServantBase; no ref-counting by >default would match TAO's and Orbix 2000's current implementation. Vote 3 changed this via issues 2441 and 4114. ServantBase is always reference counted. The discussion for these issues is useful to understand why this doesn't break legacy application code. The document that reflects these changes is ptc/01-06-07. >> 2) Is the LI::create_reference() static member function >> going to be included? What is its signature? I assume >> something like: >> >> class LI : public virtual CORBA_Object { >> public: >> static LI_ptr create_reference(LI*); >> >> but I started to wonder whether we needed an ORB_ptr in >> there as an argument. Do local objects (and their references) >> need to be associated with an ORB? > >I don't see any reason to force an association with an ORB. > >Maybe we could specify that there is an implicit conversion >* to _ptr, and avoid this extra >call? I agree that a conversion operator could (and should) be specified so that these _ptr's are created through implicit type conversion. >> 3) Do you need to do an ORB_init() to create and use local objects? >> Interestingly enough TAO works fine without an ORB_init(). > >Same with Orbix 2000. I don't think any ORB association should be >mandated. Same with ORBexpress. Bill Date: Wed, 14 Aug 2002 17:15:46 -0500 From: Paul Calabrese Reply-To: calabrese_p@ociweb.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en To: Bill Beckwith CC: "Normier, Bernhard" , Andrew Watson , Jishnu Mukerji , "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Subject: Re: C++ revision Bill Beckwith wrote: Vote 3 changed this via issues 2441 and 4114. ServantBase is always reference counted. The discussion for these issues is useful to understand why this doesn't break legacy application code. The document that reflects these changes is ptc/01-06-07. I don't see these reference counting changes to ServantBase in this document. -- Paul Calabrese Object Computing Inc. (314) 579-0066 Reply-To: "Michi Henning" From: "Michi Henning" To: , "Bill Beckwith" Cc: "Normier, Bernhard" , "Andrew Watson" , "Jishnu Mukerji" , "Linda Heaton" , "C++ Revision Task Force" Subject: Re: C++ revision Date: Thu, 15 Aug 2002 23:48:04 +1000 Organization: Triodia Technologies X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Paul Calabrese wrote: > Bill Beckwith wrote: > > Vote 3 changed this via issues 2441 and 4114. ServantBase > > is always reference counted. The discussion for these issues > > is useful to understand why this doesn't break legacy application > > code. The document that reflects these changes is ptc/01-06-07. > > I don't see these reference counting changes to ServantBase in > this document. Paul, they are definitely there. See page 1-132ff. From memory, ptc/01-06-07 was the interim report of the C++ RTF. http://www.ooc.com.au/staff/michi/cxx_revision/new_mapping_v3.pdf is identical to that. Cheers, Michi. -- Michi Henning Ph: +61 4 1118-2700 Triodia Technologies http://www.triodia.com/staff/michi Sender: jon@floorboard.com Date: Thu, 15 Aug 2002 09:52:27 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: Michi Henning CC: calabrese_p@ociweb.com, Bill Beckwith , "Normier, Bernhard" , Andrew Watson , Jishnu Mukerji , Linda Heaton , C++ Revision Task Force Subject: Re: C++ revision Michi Henning wrote: > > Paul Calabrese wrote: > > Bill Beckwith wrote: > > > Vote 3 changed this via issues 2441 and 4114. ServantBase > > > is always reference counted. The discussion for these issues > > > is useful to understand why this doesn't break legacy application > > > code. The document that reflects these changes is ptc/01-06-07. > > > > I don't see these reference counting changes to ServantBase in > > this document. > > Paul, they are definitely there. See page 1-132ff. From memory, > ptc/01-06-07 was the interim report of the C++ RTF. > http://www.ooc.com.au/staff/michi/cxx_revision/new_mapping_v3.pdf > is identical to that. Michi, that's ptc/02-01-26, not ptc/01-06-07. ptc/02-01-26 still claims it is ptc/01-06-07 on the cover page, though. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 15 Aug 2002 15:33:44 -0500 From: Paul Calabrese Reply-To: calabrese_p@ociweb.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en To: Jonathan Biggar CC: Michi Henning , Bill Beckwith , "Normier, Bernhard" , Andrew Watson , Jishnu Mukerji , Linda Heaton , C++ Revision Task Force Subject: Re: C++ revision Jonathan Biggar wrote: Michi Henning wrote: Paul Calabrese wrote: Bill Beckwith wrote: Vote 3 changed this via issues 2441 and 4114. ServantBase is always reference counted. The discussion for these issues is useful to understand why this doesn't break legacy application code. The document that reflects these changes is ptc/01-06-07. I don't see these reference counting changes to ServantBase in this document. Paul, they are definitely there. See page 1-132ff. From memory, ptc/01-06-07 was the interim report of the C++ RTF. http://www.ooc.com.au/staff/michi/cxx_revision/new_mapping_v3.pdf is identical to that. Michi, that's ptc/02-01-26, not ptc/01-06-07. ptc/02-01-26 still claims it is ptc/01-06-07 on the cover page, though. Hi, This helps a lot. I can see these changes in ptc/02-01-26. Thanks, -- Paul Calabrese Object Computing Inc. (314) 579-0066 Date: Thu, 15 Aug 2002 23:23:20 -0500 From: Paul Calabrese Reply-To: calabrese_p@ociweb.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en To: C++ Revision Task Force Subject: Re: C++ revision Normier, Bernhard wrote: Maybe we could specify that there is an implicit conversion * to _ptr, and avoid this extra call? I don't know how to define a conversion operator on the interface class that would allow conversion from a pointer. Is there some neat C++ trick to do this? This forces me to try to put the implicit conversion into the _ptr class (as a single argument constructor). Here is how this could work: - If your ORB maps LI_ptr to LI*, then do nothing and let developers do the direct assignment. - If your ORB maps LI_ptr to a class and LI is a local interface, then define constructors, LI_ptr::LI_ptr(LI*) and LI_var::LI_var(LI*) (LI_out?, others?). The compiler can use these for implicit conversions, when necessary. This should make the code: LI_var li = new LI_i; work for everyone and has the advantage of not requiring changes to the existing implementations. -- Paul Calabrese Object Computing Inc. (314) 579-0066 Sender: jon@floorboard.com Date: Thu, 15 Aug 2002 21:50:36 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: calabrese_p@ociweb.com CC: C++ Revision Task Force Subject: Re: C++ revision Paul Calabrese wrote: > > Maybe we could specify that there is an implicit conversion > > * to _ptr, and avoid this extra > > call? > > I don't know how to define a conversion operator on > the interface class that would allow conversion from > a pointer. Is there some neat C++ trick to do this? > > This forces me to try to put the implicit conversion > into the _ptr class (as a single argument constructor). > Here is how this could work: > - If your ORB maps LI_ptr to LI*, then do nothing > and let developers do the direct assignment. > - If your ORB maps LI_ptr to a class and LI is a local > interface, then define constructors, LI_ptr::LI_ptr(LI*) > and LI_var::LI_var(LI*) (LI_out?, others?). > The compiler can use these for implicit conversions, > when necessary. > > This should make the code: > > LI_var li = new LI_i; > > work for everyone and has the advantage of not > requiring changes to the existing implementations. The "LI_var::LI_var(LI*)" constructor should not be necessary, since a C++ compiler should find "LI_var(LI_ptr(new LI_i))". -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 15 Aug 2002 23:55:24 -0500 From: Paul Calabrese Reply-To: calabrese_p@ociweb.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en To: Jonathan Biggar CC: C++ Revision Task Force Subject: Re: C++ revision Jonathan Biggar wrote: Paul Calabrese wrote: Maybe we could specify that there is an implicit conversion * to _ptr, and avoid this extra call? I don't know how to define a conversion operator on the interface class that would allow conversion from a pointer. Is there some neat C++ trick to do this? This forces me to try to put the implicit conversion into the _ptr class (as a single argument constructor). Here is how this could work: - If your ORB maps LI_ptr to LI*, then do nothing and let developers do the direct assignment. - If your ORB maps LI_ptr to a class and LI is a local interface, then define constructors, LI_ptr::LI_ptr(LI*) and LI_var::LI_var(LI*) (LI_out?, others?). The compiler can use these for implicit conversions, when necessary. This should make the code: LI_var li = new LI_i; work for everyone and has the advantage of not requiring changes to the existing implementations. The "LI_var::LI_var(LI*)" constructor should not be necessary, since a C++ compiler should find "LI_var(LI_ptr(new LI_i))". Wouldn't that require the compiler to chain two user-defined conversions, which is not allowed? I tried this in a little test and I needed both constructors. -- Paul Calabrese Object Computing Inc. (314) 579-0066 Sender: jon@floorboard.com Date: Thu, 15 Aug 2002 22:09:46 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: calabrese_p@ociweb.com CC: C++ Revision Task Force Subject: Re: C++ revision Paul Calabrese wrote: > >>This forces me to try to put the implicit conversion > >>into the _ptr class (as a single argument constructor). > >>Here is how this could work: > >> - If your ORB maps LI_ptr to LI*, then do nothing > >> and let developers do the direct assignment. > >> - If your ORB maps LI_ptr to a class and LI is a local > >> interface, then define constructors, LI_ptr::LI_ptr(LI*) > >> and LI_var::LI_var(LI*) (LI_out?, others?). > >> The compiler can use these for implicit conversions, > >> when necessary. > >> > >>This should make the code: > >> > >> LI_var li = new LI_i; > >> > >>work for everyone and has the advantage of not > >>requiring changes to the existing implementations. > > > > > > The "LI_var::LI_var(LI*)" constructor should not be necessary, since a > > C++ compiler should find "LI_var(LI_ptr(new LI_i))". > > > > Wouldn't that require the compiler to chain two > user-defined conversions, which is not allowed? Constructors aren't user-defined conversions, and there's only one compiler generated conversion anyway, LI * => LI_ptr. > I tried this in a little test and I needed both > constructors. This compiles fine for me on Sun C++ 5.3: class A { }; class B { public: B(A *) { } }; class C { public: C(const B &) { } C &operator =(const B &) { return *this; } }; int main(int, char **) { C c(new A); c = new A; } -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 16 Aug 2002 09:34:18 -0500 From: Paul Calabrese Reply-To: calabrese_p@ociweb.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en To: Jonathan Biggar CC: C++ Revision Task Force Subject: Re: C++ revision Hi, See below... Jonathan Biggar wrote: Paul Calabrese wrote: This forces me to try to put the implicit conversion into the _ptr class (as a single argument constructor). Here is how this could work: - If your ORB maps LI_ptr to LI*, then do nothing and let developers do the direct assignment. - If your ORB maps LI_ptr to a class and LI is a local interface, then define constructors, LI_ptr::LI_ptr(LI*) and LI_var::LI_var(LI*) (LI_out?, others?). The compiler can use these for implicit conversions, when necessary. This should make the code: LI_var li = new LI_i; work for everyone and has the advantage of not requiring changes to the existing implementations. The "LI_var::LI_var(LI*)" constructor should not be necessary, since a C++ compiler should find "LI_var(LI_ptr(new LI_i))". Wouldn't that require the compiler to chain two user-defined conversions, which is not allowed? Constructors aren't user-defined conversions, and there's only one compiler generated conversion anyway, LI * => LI_ptr. Single argument constructors can be implicitly invoked by the compiler as user-defined conversions. I tried this in a little test and I needed both constructors. This compiles fine for me on Sun C++ 5.3: int main(int, char **) { C c(new A); c = new A; This will not work: C c2 = new A; (think of this as: LI_var li = new LI_i;) because it would require the compiler to use two user-defined conversions. That's why I added the LI_var::LI_var(LI*) constructor. -- Paul Calabrese Object Computing Inc. (314) 579-0066 Sender: jon@floorboard.com Date: Fri, 16 Aug 2002 09:35:29 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: calabrese_p@ociweb.com CC: C++ Revision Task Force Subject: Re: C++ revision Paul Calabrese wrote: > > This compiles fine for me on Sun C++ 5.3: > > > > > int main(int, char **) > > { > > C c(new A); > > > > c = new A; > > This will not work: > > C c2 = new A; > > (think of this as: LI_var li = new LI_i;) > > because it would require the compiler to use two > user-defined conversions. That's why I added the > LI_var::LI_var(LI*) constructor. Yeah, you are right. That's one of those areas where the C++ standard is broken, IMO. There's no good reason why all of the following shouldn't compile: C c(new A); C c2 = new A; c = new A; Particularly, since they all have similar look & feel and/or semantics. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 22 Aug 2002 14:06:22 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Juergen Boldt Cc: "Vinoski, Stephen" , C++ Revision Task Force , "triodia.com, michi" , Jonathan Biggar , "Normier, Bernhard" , Linda Heaton , Andrew Watson Subject: Re: C++ revision I'd say create a new issue for now. It might eventually get merged with one of the existing issues. BTW, in this discussion there is another non-C++-RTF issue lurking in there, which needs to be resolved by our esteemed OMG Technical Director or VP or whatever. The issue is what are the pieces of text that have actually been adopted already and therefore need to be published formally in the latest version of the C++ mapping specification. Without that determination and the production of such a definitive document I can't see how anyone can actually implement either a 2.6 or 3.0 C++ ORB and claim that they comply with the C++ language mapping for the same. Jishnu. Juergen Boldt wrote: > > All, > > is this discussion just general discussion, related to a certain issue, or > should this be assigned a new issue number? > > ...appreciated > > -Juergen > > At 11:40 AM 8/13/2002 -0400, Jishnu Mukerji wrote: > >Steve, > > > >Thanks, I remember now. I do have that version with me. I think what we > >should do is run it through the urgent process in the C++ RTF so that it > >can get into both 2.6 and 3.0 more or less as is. This proposed > >resolution could be enhanced to address the issue raised in Issue 4172, > >if that is deemed important. Else we could simply use Issue 4545 to do > >the urgent resolution. > > > >Until we do that, the adopted version, which is missing the factory > >operations should be in all C++ mapping chapters that came out after > >CORBA 2.4 (I believe). So Linda, which version of the C++ mapping of > >Local objects text did you have? > > > >So Yes, I do have both proposals, the adopted one and the Vinoski act II > >one. > > > >Any thoughts on how we should proceed Mr. Chair (that would be Bernard I > >presume)? > > > >Jishnu. > > > >"Vinoski, Stephen" wrote: > > > > > > The last version of a C++ mapping for LocalObject that I put together > > was not accepted, I believe by you, Jishnu, if my memory serves > > correctly. i think I remember that the last version added factory > > operations as designed by Jon, but I believe your response was that some > > deadline had passed and further changes could not be accepted at the > > time. Unfortunately I have lost all track of that whole conversation, and > > my proposals, as that all occurred years ago and I have switched laptops > > and email programs several times in the interim. > > > > > > --steve > > > > > > > -----Original Message----- > > > > From: Jishnu Mukerji [mailto:jishnu_mukerji@hp.com] > > > > Sent: Monday, August 12, 2002 12:28 PM > > > > To: C++ Revision Task Force > > > > Cc: triodia.com, michi; Jonathan Biggar; Normier, Bernhard; Linda > > > > Heaton; Andrew Watson > > > > Subject: Re: C++ revision > > > > > > > > > > > > > > > > > > > > Michi Henning wrote: > > > > > > > > > > > > > > > > > I know the TAO folks have just gone ahead and changed the > > > > POA interfaces > > > > > to > > > > > > use LocalObject, ignoring the backwards compatibility breakage. > > > > > > > > > > Those guys always were fundamentalists :-) > > > > > > > > > > > 1. Accept that changing interfaces to local breaks old code that > > > > > implemented > > > > > > POA interfaces using servants. Not wonderful, but I can > > > > live with it, > > > > > since > > > > > > the source code changes are evident and fixed in a straightforward > > > > > fashion. > > > > > > > > > > > > 2. Try to come up with a scheme where local objects can > > > > be implemented > > > > > either > > > > > > by using LocalObject or by the traditional servant route. > > > > This is more > > > > > > specification work, but cleaner, and I an live with it too. > > > > > > > > > > I would prefer option 1, even though that means some > > > > breakage (which, as > > > > > you say, can be fixed trivially). The C++ mapping is big > > > > and complex enough > > > > > as is, and so are the ORBs... Trying to keep both mappings possible > > > > > side-by-side would probably turn out rather ugly. > > > > > > > > I guess the bottom line is, no matter what we want to do with Issue > > > > 4172, 4186 and 4545, wefirst need to figure out where the adopted text > > > > penned by Steve Vinoski needs to be restored in the C++ mapping spec. > > > > > > > > Then we need to figure out what fixes need to be made to it, and make > > > > that happen very quickly. > > > > > > > > I don't think Choice 2 above can be done quickly, if ever.:-) > > > > So IMHO we > > > > should concentrate on making sure that the specification works as per > > > > choice 1. > > > > > > > > Andrew Watson said: > > > > > I agree - we can't hack out normative text as an editorial > > > > change. To get > > > > > it done quickly, we'd have to declare it urgent. > > > > > > > > > > At the moment the C++ RTF has just three members: > > > > > > > > > > Floorboard Software Jon Biggar > > > > > Hewlett-Packard Jishnu Mukerji > > > > > IONA Bernard Normier (CHAIR) > > > > > > > > > > However, the mailing list has 61 names, some of which are company > > > > > exploders. If we're going to resolve this as an urgent > > > > issue, we should at > > > > > least get opinions from other C++ ORB providers as well, including: > > > > > > > > > > 2AB > > > > > Vertel > > > > > Borland > > > > > Objective Interface Systems > > > > > Fujitsu > > > > > Prism Technology > > > > > OCI > > > > > IBM > > > > > MICO > > > > > > > > > > ... and others that I've forgotten. > > > > > > > > > > However, arguably anyone who didn't put themselves on the > > > > RTF has only > > > > > themselves to blame if it comes up with a solution they > > > > don't like :-). > > > > > > > > > > > > > > > > > BTW, what was the text that Linda sent you Michi about the C++ mapping > > > > of Local Objects? I was wondering if that was the last final version > > > > that Steve put together. I am not even sure whether the last final > > > > version that Steve put together was actually recommended by > > > > the FTF. So > > > > what might need to happen is that the text adopted by the pre-FTF > > > > adoption process needs to be inserted and perhaps the last > > > > final version > > > > with the create_ref stuff needs to be addressed as resolution to issue > > > > 4172 or some such, in an urgent manner. > > > > > > > > Sigh..... > > > > > > > > Jishnu. > > > > > > > >-- > >Jishnu Mukerji > >Senior Systems Architect, SGBU Staff > >Hewlett-Packard Company > >300 Campus Drive, MS 2E-62 > >Florham Park NJ 07932, USA > >tel:+1 973 443 7528 > >mailto:jishnu_mukerji@hp.com > > ================================= > Juergen Boldt > Director, Member Services > > Object Management Group > 250 First Avenue, Suite 201 > Needham, MA 02494 > > Tel. +1 781 444 0404 ext. 132 > Fax: +1 781 444 0320 > email: juergen@omg.org > www www.omg.org > > ================================ -- Jishnu Mukerji Senior Systems Architect, SGBU Staff Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA tel:+1 973 443 7528 mailto:jishnu_mukerji@hp.com Date: Thu, 22 Aug 2002 18:49:20 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: "Normier, Bernhard" , calabrese_p@ociweb.com, Andrew Watson , "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Subject: Re: C++ revision Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > Personally, I would like to see this situation of underspecification > > resolved soon, rather than us all sitting around and contemplating our > > navels and how many angels can dance on the head of a C++ pin for the > > next 6 months.:-) I would also prefer that whetever was decided is > > plugged into a dot dot release of CORBA 2.6 and later releases of CORBA. > > We at HP need a stable mapping for this before we put this in the HP > > Nonstop Server. > > The only thing in CORBA 2.6.1 that this issue affects is the example C++ > code in chapter 11, right? You mean the stuff in section 11.6? I believe so. We should at least fix it to reflect the material as in the adopted spec, i.e. LocalObject declared as: namespace CORBA { class LocalObject : public virtual Object { public: virtual void _add_ref() {} virtual void _remove_ref() {} // ...other pseudo ops not shown... protected: LocalObject(); ~LocalObject(); }; }; > Otherwise, there's been no formal published C++ mapping since 1999. How this happened when there has been more than one C++ RTFs that have come and gone with completed and adopted reports leaves me somewhat baffled. So how are people implementing C++ ORBs compliant with CORBA 2.6, 3.0 etc. is also a mystery. I guess they are basically winging it as far as Local Objects go. It is past time that we nailed the standard down. Meanwhile, what is the consensus on fixing the outages in the specification of the C++ mapping for LocalObjects? There was much discussion but no specific proposal. Jishnu. Sender: jbiggar@Resonate.com Date: Thu, 22 Aug 2002 16:20:02 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: "Normier, Bernhard" , calabrese_p@ociweb.com, Andrew Watson , "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Subject: Re: C++ revision Jishnu Mukerji wrote: > Meanwhile, what is the consensus on fixing the outages in the > specification of the C++ mapping for LocalObjects? There was much > discussion but no specific proposal. I guess one of us three on the RTF needs to write it up. My preference is: 1. drop the _add_ref() and _remove_ref() stuff and declare that the implementation handles reference counting automatically. 2. state that for local interface Foo, the IDL compiler generates the proper conversion magic to make a Foo * turn into a Foo_ptr automatically. We also need an explict example to show how to implement a local object, since end user-programmers have to be able to do it to handle Portable Intercetors. Something like: // IDL module M { local interface LI { void op(...); }; }; // C++ class MyLI : public M::LI, public CORBA::LocalObject { public: ... void op(...); ... }; -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 22 Aug 2002 19:35:40 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: "Normier, Bernhard" , calabrese_p@ociweb.com, Andrew Watson , "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Subject: Re: C++ revision There is also this minor matter of which is the base document that we are working with. I suspect it is ptc/02-01-26 together with the Section 1.35 that was adopted as part of the Components adoption process inserted into ptc/02-01-26 at an appropriate place, like as section 1.35? We should perhaps create a fixed up base document to avoid confusion. Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > Meanwhile, what is the consensus on fixing the outages in the > > specification of the C++ mapping for LocalObjects? There was much > > discussion but no specific proposal. > > I guess one of us three on the RTF needs to write it up. My preference > is: > > 1. drop the _add_ref() and _remove_ref() stuff and declare that the > implementation handles reference counting automatically. Does this get rid of the need to standardize things like RefCountedLocalObject as in the Iona and TAO implementations? Are Iona and TAO folks ready to go along with thenmandatory ref counting or not is an issue that we should resolve up front. > > 2. state that for local interface Foo, the IDL compiler generates the > proper conversion magic to make a Foo * turn into a Foo_ptr > automatically. Do we need to specify what the magic is? > > We also need an explict example to show how to implement a local > object, > since end user-programmers have to be able to do it to handle > Portable > Intercetors. Something like: > > // IDL > module M { > local interface LI { > void op(...); > }; > }; > > // C++ > class MyLI : public M::LI, public CORBA::LocalObject { > public: > ... > void op(...); > ... > }; Yes. Jishnu. Date: Fri, 23 Aug 2002 09:35:34 -0500 From: Paul Calabrese Reply-To: calabrese_p@ociweb.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en To: Jishnu Mukerji CC: Jonathan Biggar , "Normier, Bernhard" , Andrew Watson , "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Subject: Re: C++ revision Jishnu Mukerji wrote: There is also this minor matter of which is the base document that we are working with. I suspect it is ptc/02-01-26 together with the Section 1.35 that was adopted as part of the Components adoption process inserted into ptc/02-01-26 at an appropriate place, like as section 1.35? We should perhaps create a fixed up base document to avoid confusion. Jonathan Biggar wrote: Jishnu Mukerji wrote: Meanwhile, what is the consensus on fixing the outages in the specification of the C++ mapping for LocalObjects? There was much discussion but no specific proposal. I guess one of us three on the RTF needs to write it up. My preference is: 1. drop the _add_ref() and _remove_ref() stuff and declare that the implementation handles reference counting automatically. Does this get rid of the need to standardize things like RefCountedLocalObject as in the Iona and TAO implementations? Yes. Are Iona and TAO folks ready to go along with thenmandatory ref counting or not is an issue that we should resolve up front. I can't speak for all the TAO folks, but I don't see a problem changing this. 2. state that for local interface Foo, the IDL compiler generates the proper conversion magic to make a Foo * turn into a Foo_ptr automatically. Do we need to specify what the magic is? I don't think its necessary. We also need an explict example to show how to implement a local object, since end user-programmers have to be able to do it to handle Portable Intercetors. Something like: // IDL module M { local interface LI { void op(...); }; }; // C++ class MyLI : public M::LI, public CORBA::LocalObject { public: ... void op(...); ... }; Yes. -- Paul Calabrese Object Computing Inc. (314) 579-0066 X-Sender: andrew@192.67.184.65 Date: Fri, 23 Aug 2002 23:00:02 +0100 To: Jishnu Mukerji From: Andrew Watson Subject: Issue 5579 [Was: Re: C++ revision] Cc: calabrese_p@ociweb.com, "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Jishnu, You wrote: > There is also this minor matter of which is the base document that we > are working with. I suspect it is ptc/02-01-26 together with the Section > 1.35 that was adopted as part of the Components adoption process > inserted into ptc/02-01-26 at an appropriate place, like as section > 1.35? We should perhaps create a fixed up base document to avoid > confusion. Since the Local Object mapping text is part of an adopted OMG spec (CCM), and Local Objects have already been added to published versions of CORBA 2.x, adding this "lost" text back into the C++ mapping spec is actually an editorial issue. Even if it's broken, it should be there until the RTF fixes it. I've therefore editorially created a version of ptc/02-01-26 (the final C++ chapter delivered by the last C++ RTF in April 2002) with the lost Local Object mapping text added back. This new document is ptc/02-08-08, and should be used as the basis for any revision of the C++ Local Object mapping. http://doc.omg.org/ptc/02-08-08 C++ mapping with CCM local object text The lost Local Object Mapping text is also available as ptc/02-08-06 - this is the document that Jishnu circulated by email a few days ago. http://doc.omg.org/ptc/02-08-06 Stand-alone CCM local object text Of course, there is a potential problem with this Local Object mapping - it breaks servant manager implementations because they are currently ordinary servants. The RTF has to decide if this really is a problem, and if it is, how to fix it. Steve Vinoski's proposed update to the Local Object mapping section is available as ptc/02-08-07. http://doc.omg.org/ptc/02-08-06 Steve's proposed local object mapping To help Juergen keep track of this issue, please put the issue number (5579) in the subject line of messages about it. By default, the next published version of the C++ mapping WILL INCLUDE the CCM local object mapping. If the RTF wants to change this adopted text now, rather than wait until the RTF publishes its report in Feb 2003, this issue (5579) will have to be declared urgent. Cheers, Andrew X-Sender: andrew@192.67.184.65 Date: Fri, 23 Aug 2002 23:04:33 +0100 To: Jonathan Biggar From: Andrew Watson Subject: Re: Issue 5579 [Was: Re: C++ revision] Cc: Jishnu Mukerji , "Normier, Bernhard" , calabrese_p@ociweb.com, "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Jon, You wrote: > > Meanwhile, what is the consensus on fixing the outages in the > > specification of the C++ mapping for LocalObjects? There was much > > discussion but no specific proposal. > > I guess one of us three on the RTF needs to write it up. My > > preference > is: > > 1. drop the _add_ref() and _remove_ref() stuff and declare that the > implementation handles reference counting automatically. > > 2. state that for local interface Foo, the IDL compiler generates > > the > proper conversion magic to make a Foo * turn into a Foo_ptr > automatically. > > We also need an explict example to show how to implement a local > > object, > since end user-programmers have to be able to do it to handle > > Portable > Intercetors. Something like: > > // IDL > module M { > local interface LI { > void op(...); > }; > }; > > // C++ > class MyLI : public M::LI, public CORBA::LocalObject { > public: > ... > void op(...); > ... > }; Can I encourage you to write up your proposal? You can do it as a set of changes to ptc/02-08-08 - this is the C++ mapping with the CCM local object text that I've just uploaded. The Frame source is available on the server: http://doc.omg.org/ptc/02-08-08 Thanks, Andrew Sender: jbiggar@Resonate.com Date: Thu, 29 Aug 2002 14:14:36 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: Andrew Watson CC: Jishnu Mukerji , calabrese_p@ociweb.com, "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Subject: Re: Issue 5579 [Was: Re: C++ revision] Andrew Watson wrote: > I've therefore editorially created a version of ptc/02-01-26 (the final C++ > chapter delivered by the last C++ RTF in April 2002) with the lost Local > Object mapping text added back. This new document is ptc/02-08-08, and > should be used as the basis for any revision of the C++ Local Object > mapping. > > http://doc.omg.org/ptc/02-08-08 C++ mapping with CCM local object text > > The lost Local Object Mapping text is also available as ptc/02-08-06 - this > is the document that Jishnu circulated by email a few days ago. > > http://doc.omg.org/ptc/02-08-06 Stand-alone CCM local object text > > Of course, there is a potential problem with this Local Object mapping - it > breaks servant manager implementations because they are currently ordinary > servants. The RTF has to decide if this really is a problem, and if it is, > how to fix it. Steve Vinoski's proposed update to the Local Object mapping > section is available as ptc/02-08-07. > > http://doc.omg.org/ptc/02-08-06 Steve's proposed local object mapping > > To help Juergen keep track of this issue, please put the issue number > (5579) in the subject line of messages about it. > > By default, the next published version of the C++ mapping WILL INCLUDE the > CCM local object mapping. If the RTF wants to change this adopted text now, > rather than wait until the RTF publishes its report in Feb 2003, this issue > (5579) will have to be declared urgent. Ok, I don't think it is a good idea for the RTF to let this get published and then have to immediately tweak it because we know there are some outstanding issues. So, unless there is an objection from the chair, I'd like to formally request that this issue be declared urgent. Here is my proposed resolution: 1. Remove _add_ref() and _remove_ref(), and declare that LocalObject handles its own reference counting internally. 2. Add magic text that requires a pointer to a LocalObject to automatically convert to a _ptr. Here is my proposed replacement text for 1.35: -------------------------------- 1.35 Local Object The C++ mapping of Local Object is a class derived from CORBA::Object that is used as a base class for locality constrained object implementations. A locality constrained object is implemented by a class derived both from the class mapping the interface and from CORBA::LocalObject. namespace CORBA { class LocalObject : public virtual Object { public: // ...other pseudo ops not shown... protected: LocalObject(); ~LocalObject(); }; }; Member functions and any data members needed to implement the Object pseudo-operations and any other ORB support functions shall also be supplied but are not shown. The implementation of LocalObject must provide a thread-safe mechanism for managing the lifecycle of a local object reference via _duplicate() and release(). The destructor of a local object implementation will automatically be called when the last reference to it has been released. The IDL compiler will generate appropriate conversion operations to allow a pointer to a local object implementation to be automatically converted to the corresponding _ptr or _var type. Here is an example of how to implement a local interface: // IDL interface LocalIF { void an_op(in long an_arg); }; // C++ class MyLocalIF : public LocalIF, public CORBA::LocalObject { public: MyLocalIF(...); ~MyLocalIF(); void an_op(CORBA::Long an_arg); }; Local_IF_var a_local_if = new MyLocalIF(...); a_local_if->an_op(1L); // the local object is destroyed when a_local_if goes out of scope --------------------------------- -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 29 Aug 2002 17:37:29 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: C++ Revision Task Force Cc: Jonathan Biggar , Andrew Watson , calabrese_p@ociweb.com, "triodia.com, michi" , Linda Heaton Subject: Re: Issue 5579 [Was: Re: C++ revision] Jon's proposals seems to capture the spirit of what has been discussed so far. I think it is a good idea to resolve this ASAP. My primary interest is in getting a published C++ language mapping standard out that allows a pubslished specification consistent implementation of CORBA 2.6 or 3.0 in C++ possible. At present, clearly all the C++ implementations of all versions of CORBA post 2.4 (inclusive) are standing on thin air as far as having anything to do with any standard is concerned:-(, since no C++ mapping seems to have been formally published which includes mappings for Local Objects. This needs to be fixed ASAP. Thanks, Jishnu. Jonathan Biggar wrote: > > Andrew Watson wrote: > > I've therefore editorially created a version of ptc/02-01-26 (the final C++ > > chapter delivered by the last C++ RTF in April 2002) with the lost Local > > Object mapping text added back. This new document is ptc/02-08-08, and > > should be used as the basis for any revision of the C++ Local Object > > mapping. > > > > http://doc.omg.org/ptc/02-08-08 C++ mapping with CCM local object text > > > > The lost Local Object Mapping text is also available as ptc/02-08-06 - this > > is the document that Jishnu circulated by email a few days ago. > > > > http://doc.omg.org/ptc/02-08-06 Stand-alone CCM local object text > > > > Of course, there is a potential problem with this Local Object mapping - it > > breaks servant manager implementations because they are currently ordinary > > servants. The RTF has to decide if this really is a problem, and if it is, > > how to fix it. Steve Vinoski's proposed update to the Local Object mapping > > section is available as ptc/02-08-07. > > > > http://doc.omg.org/ptc/02-08-06 Steve's proposed local object mapping > > > > To help Juergen keep track of this issue, please put the issue number > > (5579) in the subject line of messages about it. > > > > By default, the next published version of the C++ mapping WILL INCLUDE the > > CCM local object mapping. If the RTF wants to change this adopted text now, > > rather than wait until the RTF publishes its report in Feb 2003, this issue > > (5579) will have to be declared urgent. > > Ok, I don't think it is a good idea for the RTF to let this get > published and then have to immediately tweak it because we know there > are some outstanding issues. > > So, unless there is an objection from the chair, I'd like to formally > request that this issue be declared urgent. > > Here is my proposed resolution: > > 1. Remove _add_ref() and _remove_ref(), and declare that LocalObject > handles its own reference counting internally. > > 2. Add magic text that requires a pointer to a LocalObject to > automatically convert to a _ptr. > > Here is my proposed replacement text for 1.35: > > -------------------------------- > 1.35 Local Object > > The C++ mapping of Local Object is a class derived from CORBA::Object > that is used as a base class for locality constrained object > implementations. A locality constrained object is implemented by a class > derived both from the class mapping the interface and from > CORBA::LocalObject. > > namespace CORBA > { > class LocalObject : public virtual Object > { > public: > // ...other pseudo ops not shown... > protected: > LocalObject(); > ~LocalObject(); > }; > }; > > Member functions and any data members needed to implement the Object > pseudo-operations and any other ORB support functions shall also be > supplied but are not shown. > > The implementation of LocalObject must provide a thread-safe mechanism > for managing the lifecycle of a local object reference via _duplicate() > and release(). The destructor of a local object implementation will > automatically be called when the last reference to it has been released. > > The IDL compiler will generate appropriate conversion operations to > allow a pointer to a local object implementation to be automatically > converted to the corresponding _ptr or _var type. > > Here is an example of how to implement a local interface: > > // IDL > interface LocalIF { > void an_op(in long an_arg); > }; > > // C++ > class MyLocalIF : public LocalIF, public CORBA::LocalObject { > public: > MyLocalIF(...); > ~MyLocalIF(); > > void an_op(CORBA::Long an_arg); > }; > > Local_IF_var a_local_if = new MyLocalIF(...); > > a_local_if->an_op(1L); > > // the local object is destroyed when a_local_if goes out of scope > > --------------------------------- > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org -- Jishnu Mukerji Senior Systems Architect Hewlett-Packard Company Technology Office 300 Campus Drive, MS 2E-62 Software Global Business Unit Florham Park NJ 07932, USA mailto: jishnu_mukerji@hp.com Tel: +1 973 443 7528 Subject: RE: Issue 5579 [Was: Re: C++ revision] Date: Thu, 29 Aug 2002 17:54:51 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 5579 [Was: Re: C++ revision] Thread-Index: AcJPomv1J0J8ImihTaCuHB8IT8vbPAAAn/8A From: "Normier, Bernhard" To: "Jonathan Biggar" , "Andrew Watson" Cc: "Jishnu Mukerji" , , "triodia.com, michi" , "Linda Heaton" , "C++ Revision Task Force" X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id g7TLpHX19976 Hi Jonathan, > > (5579) will have to be declared urgent. > > Ok, I don't think it is a good idea for the RTF to let this get > published and then have to immediately tweak it because we know there > are some outstanding issues. My understanding is that the problematic part is the servant manager implementation, which is not discussed by your proposal. > > So, unless there is an objection from the chair, I'd like to > formally > request that this issue be declared urgent. > > Here is my proposed resolution: > > 1. Remove _add_ref() and _remove_ref(), and declare that > LocalObject > handles its own reference counting internally. I'd like to keep these member functions, to allow different yet portable ref counting implementation, such as no-op or with control over the mutex used. > > 2. Add magic text that requires a pointer to a LocalObject to > automatically convert to a _ptr. Ok. > > Here is my proposed replacement text for 1.35: > > -------------------------------- > 1.35 Local Object > > The C++ mapping of Local Object is a class derived from > CORBA::Object > that is used as a base class for locality constrained object > implementations. A locality constrained object is implemented > by a class > derived both from the class mapping the interface and from > CORBA::LocalObject. > > namespace CORBA > { > class LocalObject : public virtual Object > { > public: > // ...other pseudo ops not shown... > protected: > LocalObject(); > ~LocalObject(); > }; > }; > > Member functions and any data members needed to implement the Object > pseudo-operations and any other ORB support functions shall also be > supplied but are not shown. > > The implementation of LocalObject must provide a thread-safe > mechanism > for managing the lifecycle of a local object reference via > _duplicate() > and release(). The destructor of a local object implementation will > automatically be called when the last reference to it has > been released. I'm happy with a ref-counted thread-safe LocalObject implementation. > > The IDL compiler will generate appropriate conversion operations to > allow a pointer to a local object implementation to be automatically > converted to the corresponding _ptr or _var type. > > Here is an example of how to implement a local interface: > > // IDL > interface LocalIF { > void an_op(in long an_arg); > }; > > // C++ > class MyLocalIF : public LocalIF, public CORBA::LocalObject { > public: > MyLocalIF(...); > ~MyLocalIF(); > > void an_op(CORBA::Long an_arg); > }; It would be nice to resolve issue #4496 with this resolution as well. Issue #4496 suggests to have the abstract class generated from interface LocalIF derive from CORBA::LocalObject. > > Local_IF_var a_local_if = new MyLocalIF(...); > > a_local_if->an_op(1L); > > // the local object is destroyed when a_local_if goes out of scope > Thanks, Bernard Sender: jbiggar@Resonate.com Date: Thu, 29 Aug 2002 15:15:20 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: "Normier, Bernhard" CC: Andrew Watson , Jishnu Mukerji , calabrese_p@ociweb.com, "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Subject: Re: Issue 5579 [Was: Re: C++ revision] "Normier, Bernhard" wrote: > > Hi Jonathan, > > > > (5579) will have to be declared urgent. > > > > Ok, I don't think it is a good idea for the RTF to let this get > > published and then have to immediately tweak it because we know there > > are some outstanding issues. > > My understanding is that the problematic part is the servant manager > implementation, which is not discussed by your proposal. That is another problematic part. Unless we decide that we have to solve it to avoid breaking code, the default of this proposal will be to allow code to break. > > So, unless there is an objection from the chair, I'd like to formally > > request that this issue be declared urgent. > > > > Here is my proposed resolution: > > > > 1. Remove _add_ref() and _remove_ref(), and declare that LocalObject > > handles its own reference counting internally. > > I'd like to keep these member functions, to allow different yet > portable ref counting implementation, such as no-op or with control > over the mutex used. I'm not convinced. I can't see any useful user defined ref counting functions that are portable. If there aren't any, then an ORB implementation can just provide a non-standard mixin class to change the refcounting behavior, which gives the user the same ability. > > 2. Add magic text that requires a pointer to a LocalObject to > > automatically convert to a _ptr. > > Ok. > > > > > Here is my proposed replacement text for 1.35: > > > > -------------------------------- > > 1.35 Local Object > > > > The C++ mapping of Local Object is a class derived from CORBA::Object > > that is used as a base class for locality constrained object > > implementations. A locality constrained object is implemented > > by a class > > derived both from the class mapping the interface and from > > CORBA::LocalObject. > > > > namespace CORBA > > { > > class LocalObject : public virtual Object > > { > > public: > > // ...other pseudo ops not shown... > > protected: > > LocalObject(); > > ~LocalObject(); > > }; > > }; > > > > Member functions and any data members needed to implement the Object > > pseudo-operations and any other ORB support functions shall also be > > supplied but are not shown. > > > > The implementation of LocalObject must provide a thread-safe mechanism > > for managing the lifecycle of a local object reference via > > _duplicate() > > and release(). The destructor of a local object implementation will > > automatically be called when the last reference to it has > > been released. > > I'm happy with a ref-counted thread-safe LocalObject implementation. > > > > > The IDL compiler will generate appropriate conversion operations to > > allow a pointer to a local object implementation to be automatically > > converted to the corresponding _ptr or _var type. > > > > Here is an example of how to implement a local interface: > > > > // IDL > > interface LocalIF { > > void an_op(in long an_arg); > > }; > > > > // C++ > > class MyLocalIF : public LocalIF, public CORBA::LocalObject { > > public: > > MyLocalIF(...); > > ~MyLocalIF(); > > > > void an_op(CORBA::Long an_arg); > > }; > > It would be nice to resolve issue #4496 with this resolution as > well. Issue #4496 suggests to have the abstract class generated > from interface LocalIF derive from CORBA::LocalObject. Hmmm, the suggested approach there conflicts with the idea of allowing local object implementations still be usable via POA mediated servants. Also, the issue states that the IDL compiler/ORB can't enforce the requirement to inherit from LocalObject, which is incorrect. All it needs to do is define a pure virtual function in either CORBA::Object or the generated interface class that is only satisfied if you also inherit from LocalObject. (For normal interfaces, the IDL compiler can generate the redefined virtual function itself.) Also, I don't think that allowing is_a("IDL:omg.org/CORBA/LocalObject:1.0") is a good idea. I don't think "IDL:omg.org/CORBA/LocalObject:1.0" even exists. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Subject: RE: Issue 5579 [Was: Re: C++ revision] Date: Thu, 29 Aug 2002 18:26:38 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 5579 [Was: Re: C++ revision] Thread-Index: AcJPqZ3F4YmgwCSgSXqg99otbi2lUAAAFXhg From: "Normier, Bernhard" To: "Jonathan Biggar" Cc: "Andrew Watson" , "Jishnu Mukerji" , , "triodia.com, michi" , "Linda Heaton" , "C++ Revision Task Force" X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id g7TMMxX20307 Hi Jon, > > > 1. Remove _add_ref() and _remove_ref(), and declare that > LocalObject > > > handles its own reference counting internally. > > > > I'd like to keep these member functions, to allow different yet > > portable ref counting implementation, such as no-op or with control > > over the mutex used. > So I'll expand on my examples: - no-op makes a stack-allocated LocalObject possible, and even for heap allocated allows to avoid the sometimes quite expensive but not necessary ref-counting operations. - control over mutex used allows to properly manage a container of local objects, and correctly (with no risk of deadlock) remove an' object from this container upon release of its last ref-count. What's the harm is keeping these functions? Since they were specified a long time ago, it's also likely that user some code already depends on them. Cheers, Bernard Date: Thu, 29 Aug 2002 18:35:11 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: "Normier, Bernhard" Cc: Jonathan Biggar , Andrew Watson , calabrese_p@ociweb.com, "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Subject: Re: Issue 5579 [Was: Re: C++ revision] Yep, we could keep them around for backward compatibility. But we should hang a huge notice over them saying something like "Do not use unless you absolutely positively know what you are doing, and if after using you find that objects are either hanging around or disappearing unexpectedly, don't go about blaming anyone else".:-) IOW, more seriously, point out clearly that in the normal course of things no one should need to use them. They are present only for historical reasons. Moreover, if we do keep them around then resolving this issue becomes less urgent, no? Jishnu. "Normier, Bernhard" wrote: > > Hi Jon, > > > > > 1. Remove _add_ref() and _remove_ref(), and declare that > > LocalObject > > > > handles its own reference counting internally. > > > > > > I'd like to keep these member functions, to allow different yet > > > portable ref counting implementation, such as no-op or with control > > > over the mutex used. > > > > So I'll expand on my examples: > > - no-op makes a stack-allocated LocalObject possible, and even for > heap allocated allows to avoid the sometimes quite expensive but not > necessary ref-counting operations. > > - control over mutex used allows to properly manage a container of > local objects, and correctly (with no risk of deadlock) remove an' > object from this container upon release of its last ref-count. > > What's the harm is keeping these functions? Since they were specified > a long time ago, it's also likely that user some code already depends > on them. > > Cheers, > Bernard -- Jishnu Mukerji Senior Systems Architect Hewlett-Packard Company Technology Office 300 Campus Drive, MS 2E-62 Software Global Business Unit Florham Park NJ 07932, USA mailto: jishnu_mukerji@hp.com Tel: +1 973 443 7528 Date: Fri, 30 Aug 2002 10:29:31 -0500 From: Paul Calabrese Reply-To: calabrese_p@ociweb.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en To: "Normier, Bernhard" CC: Jonathan Biggar , Andrew Watson , Jishnu Mukerji , "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Subject: Re: Issue 5579 [Was: Re: C++ revision] Normier, Bernhard wrote: Hi Jon, 1. Remove _add_ref() and _remove_ref(), and declare that LocalObject handles its own reference counting internally. I'd like to keep these member functions, to allow different yet portable ref counting implementation, such as no-op or with control over the mutex used. So I'll expand on my examples: - no-op makes a stack-allocated LocalObject possible, and even for heap allocated allows to avoid the sometimes quite expensive but not necessary ref-counting operations. > - control over mutex used allows to properly manage a container of local objects, and correctly (with no risk of deadlock) remove an' object from this container upon release of its last ref-count. What's the harm is keeping these functions? Since they were specified a long time ago, it's also likely that user some code already depends on them. This is an excellent summary of the reasons. I agree that the ability to disable the reference counting should be kept. -- Paul Calabrese Object Computing Inc. (314) 579-0066 Sender: jbiggar@Resonate.com Date: Tue, 03 Sep 2002 10:57:07 -0700 From: Jonathan Biggar X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en To: "Normier, Bernhard" CC: Andrew Watson , Jishnu Mukerji , calabrese_p@ociweb.com, "triodia.com, michi" , Linda Heaton , C++ Revision Task Force Subject: Re: Issue 5579 [Was: Re: C++ revision] "Normier, Bernhard" wrote: > > > > 1. Remove _add_ref() and _remove_ref(), and declare that > > LocalObject > > > > handles its own reference counting internally. > > > > > > I'd like to keep these member functions, to allow different yet > > > portable ref counting implementation, such as no-op or with control > > > over the mutex used. > > > > So I'll expand on my examples: > > - no-op makes a stack-allocated LocalObject possible, and even for > heap allocated allows to avoid the sometimes quite expensive but not > necessary ref-counting operations. Having the reference count mechanism built in to LocalObject does not preclude stack allocated LocalObjects. See the discussion of issue 4114 which resulted in changing ServantBase to do reference counting by default. But even so, I thnk stack based LocalObjects are much less usable than stack based servants. The difference is that for a POA servant, you have much more control over where references to the servant end up, and with only a small amount of care, you can be reasonably sure that the servant is not used beyond the lifetime of its stack allocation, primarily by ensuring that the ORB is shutdown before the servant's stack space is deallocated However, for LocalObjects, you don't have that measure of control. This makes stack allocated LocalObjects inherently more dangerous. > - control over mutex used allows to properly manage a container of > local objects, and correctly (with no risk of deadlock) remove an' > object from this container upon release of its last ref-count. Once you bring up explicit use of a 'mutex', you are already talking about non-portable code, since the C++ mapping has no standard mutex type. The same effect can be achieved portably by adding an extra layer of indirection, where the local object reference delegates to an actual implementation object that is managed as needed. > What's the harm is keeping these functions? Since they were specified > a long time ago, it's also likely that user some code already depends > on them. The functions are useless as specified now for writing portable code. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Subject: Proposal for C++ local interface mapping (issue #5579) Date: Mon, 2 Dec 2002 16:23:51 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for C++ local interface mapping (issue #5579) Thread-Index: AcKaSR2GVtkkWsaDT5ujBn6JQxAT6w== From: "Normier, Bernhard" To: X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id gB2LNa304321 The C++ local interface mapping still needs to be addressed; a resolution could/should address a number of open issues (4160, 4172, 4186, 4245, 4496, 4545, 5579, 5580). Unfortunately there was no consensus on Jon's proposal a few months ago, and I don't see how an agreement or consensus on the _add_ref/_remove_ref could be reached. To resolve this matter, I suggest to vote on two proposals: - the mapping of local interface with _add_ref and _remove_ref (thread-safe by default) - the removal of _add_ref and _remove_ref from CORBA::LocalObject (which I strongly oppose). You will find draft proposals below; I intend to submit them to a vote (after discussion and amendment if necessary) in the next few days. Cheers, Bernard =========================================================== A. C++ Local interface mapping (derived from Jon's proposal) =========================================================== - Require the IDL compiler to generate if necessary conversion functions that transparently convert pointers to local objects to _ptrs. - We do not introduce any special mapping for interfaces that used to be non-local such as the ServantManagers; older code that implemented them using servants will have to be updated. - The ref-counting text was borrowed from the POA ServantBase. New text for 1.35: ----------------- 1.35 Local Object The C++ mapping of Local Object is a class derived from CORBA::Object that is used as a base class for locality constrained object implementations. A locality constrained object is implemented by a class derived both from the class mapping the interface and from CORBA::LocalObject. namespace CORBA { class LocalObject : public virtual Object { public: virtual void _add_ref(); virtual void _remove_ref(); virtual ULong _refcount_value() const; // ...other pseudo ops not shown... protected: LocalObject(); ~LocalObject(); }; }; Member functions and any data members needed to implement the Object pseudo-operations and any other ORB support functions shall also be supplied but are not shown. The IDL compiler will generate appropriate conversion operations to allow a pointer to a local object implementation to be automatically converted to the corresponding _ptr or _var type. Local object instances implement reference counting to prevent themselves from being destroyed while the application is still using them. The constructor and copy constructor initialize the reference count member to one. The assignment operator returns *this and does not affect the reference count. _refcount_value returns the current value of the reference count member. _add_ref increments the reference count member by one. _remove_ref decrements the reference count member by one; if the resulting reference count equals ezero, _remove_ref invokes delete on its this pointer in order to destroy the local object. For ORBs that operate in multi-threaded environments, the implementations of _refcount_value, _add_ref, and _remove_ref shall be thread-safe. Local objects can be allocated on the stack even though they are reference-counted: because the constructor sets the initial reference count to one, and the program makes an equal number of calls to _add_ref and _remove_ref, when the local object is popped off the stack, the destructor simply destroys a local object with a reference count of one (that is, the reference count never drops to zero). Note that reference counting can be disabled completely by providing no-op implementations of _add_ref and _remove_ref in the derived local object implementation. Here is an example of how to implement a local interface: // IDL interface LocalIF { void an_op(in long an_arg); }; // C++ class MyLocalIF : public LocalIF, public CORBA::LocalObject { public: MyLocalIF(...); ~MyLocalIF(); void an_op(CORBA::Long an_arg); }; =========================================================== B. _add_ref/_remove_ref removal =========================================================== - _add_ref/_remove_ref are useless and should be removed. - Replace "Local object instances .... the derived local object implementation." in the text proposal above by: ---- The implementation of LocalObject must provide a thread-safe mechanism for managing the lifecycle of a local object reference via _duplicate() and release(). The destructor of a local object implementation will automatically be called when the last reference to it has been released. ---- Subject: Proposal for C++ local interface mapping (issue #5579) Date: Mon, 2 Dec 2002 16:23:51 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for C++ local interface mapping (issue #5579) Thread-Index: AcKaSR2GVtkkWsaDT5ujBn6JQxAT6w== From: "Normier, Bernhard" To: X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id gB2LNa304321 The C++ local interface mapping still needs to be addressed; a resolution could/should address a number of open issues (4160, 4172, 4186, 4245, 4496, 4545, 5579, 5580). Unfortunately there was no consensus on Jon's proposal a few months ago, and I don't see how an agreement or consensus on the _add_ref/_remove_ref could be reached. To resolve this matter, I suggest to vote on two proposals: - the mapping of local interface with _add_ref and _remove_ref (thread-safe by default) - the removal of _add_ref and _remove_ref from CORBA::LocalObject (which I strongly oppose). You will find draft proposals below; I intend to submit them to a vote (after discussion and amendment if necessary) in the next few days. Cheers, Bernard =========================================================== A. C++ Local interface mapping (derived from Jon's proposal) =========================================================== - Require the IDL compiler to generate if necessary conversion functions that transparently convert pointers to local objects to _ptrs. - We do not introduce any special mapping for interfaces that used to be non-local such as the ServantManagers; older code that implemented them using servants will have to be updated. - The ref-counting text was borrowed from the POA ServantBase. New text for 1.35: ----------------- 1.35 Local Object The C++ mapping of Local Object is a class derived from CORBA::Object that is used as a base class for locality constrained object implementations. A locality constrained object is implemented by a class derived both from the class mapping the interface and from CORBA::LocalObject. namespace CORBA { class LocalObject : public virtual Object { public: virtual void _add_ref(); virtual void _remove_ref(); virtual ULong _refcount_value() const; // ...other pseudo ops not shown... protected: LocalObject(); ~LocalObject(); }; }; Member functions and any data members needed to implement the Object pseudo-operations and any other ORB support functions shall also be supplied but are not shown. The IDL compiler will generate appropriate conversion operations to allow a pointer to a local object implementation to be automatically converted to the corresponding _ptr or _var type. Local object instances implement reference counting to prevent themselves from being destroyed while the application is still using them. The constructor and copy constructor initialize the reference count member to one. The assignment operator returns *this and does not affect the reference count. _refcount_value returns the current value of the reference count member. _add_ref increments the reference count member by one. _remove_ref decrements the reference count member by one; if the resulting reference count equals ezero, _remove_ref invokes delete on its this pointer in order to destroy the local object. For ORBs that operate in multi-threaded environments, the implementations of _refcount_value, _add_ref, and _remove_ref shall be thread-safe. Local objects can be allocated on the stack even though they are reference-counted: because the constructor sets the initial reference count to one, and the program makes an equal number of calls to _add_ref and _remove_ref, when the local object is popped off the stack, the destructor simply destroys a local object with a reference count of one (that is, the reference count never drops to zero). Note that reference counting can be disabled completely by providing no-op implementations of _add_ref and _remove_ref in the derived local object implementation. Here is an example of how to implement a local interface: // IDL interface LocalIF { void an_op(in long an_arg); }; // C++ class MyLocalIF : public LocalIF, public CORBA::LocalObject { public: MyLocalIF(...); ~MyLocalIF(); void an_op(CORBA::Long an_arg); }; =========================================================== B. _add_ref/_remove_ref removal =========================================================== - _add_ref/_remove_ref are useless and should be removed. - Replace "Local object instances .... the derived local object implementation." in the text proposal above by: ---- The implementation of LocalObject must provide a thread-safe mechanism for managing the lifecycle of a local object reference via _duplicate() and release(). The destructor of a local object implementation will automatically be called when the last reference to it has been released. ---- From: "Pilhofer, Frank" To: "'Normier, Bernhard'" , cxx_revision@omg.org Subject: RE: Proposal for C++ local interface mapping (issue #5579) Date: Tue, 3 Dec 2002 11:42:58 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) > > Here is an example of how to implement a local interface: > > // IDL > interface LocalIF { > void an_op(in long an_arg); > }; > > // C++ > class MyLocalIF : public LocalIF, public CORBA::LocalObject { > public: > MyLocalIF(...); > ~MyLocalIF(); > > void an_op(CORBA::Long an_arg); > }; > Hi Bernhard, this is not a local interface, it's an interface that happens to have a local implementation. And I figure that the above is dangerous, since it requires the stub (LocalIF) to have a specific layout. I suggest that for a local interface (with the local keyword), the IDL-generated class should already inherit from LocalObject: // IDL local interface LocalIF { void an_op (in long an_arg); }; // C++ class MyLocalIF : public LocalIF { // same as above }; I think that providing a local implementation for a non-local interface (as in pseudo IDL) should be out of scope of the C++ mapping, we have well-defined mechanisms in the POA for that. Frank Subject: RE: Proposal for C++ local interface mapping (issue #5579) Date: Tue, 3 Dec 2002 12:06:58 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Proposal for C++ local interface mapping (issue #5579) Thread-Index: AcKa6xc3bGuu7mwiTmWqy5VXEj/PGwAAaaSg From: "Normier, Bernhard" To: "Pilhofer, Frank" , Hi Frank, > I suggest that for a local interface (with the local keyword), the > IDL-generated class should already inherit from LocalObject: I think there is a consensus to reject such mapping (suggested by issue #4496) (see attached e-mail). > I think that providing a local implementation for a non-local > interface > (as in pseudo IDL) should be out of scope of the C++ mapping, we > have > well-defined mechanisms in the POA for that. I disagree. Since local implementations of both local and non local interfaces are possible, the C++ mapping should specify both. BTW this has nothing to do with pseudo IDL. Cheers, Bernard > -----Original Message----- > From: Pilhofer, Frank [mailto:fpilhofe@mc.com] > Sent: Tuesday, December 03, 2002 11:43 AM > To: Normier, Bernhard; cxx_revision@omg.org > Subject: RE: Proposal for C++ local interface mapping (issue #5579) > > > > > > Here is an example of how to implement a local interface: > > > > // IDL > > interface LocalIF { > > void an_op(in long an_arg); > > }; > > > > // C++ > > class MyLocalIF : public LocalIF, public CORBA::LocalObject { > > public: > > MyLocalIF(...); > > ~MyLocalIF(); > > > > void an_op(CORBA::Long an_arg); > > }; > > > > Hi Bernhard, > > this is not a local interface, it's an interface that happens to have > a local implementation. And I figure that the above is > dangerous, since > it requires the stub (LocalIF) to have a specific layout. > > I suggest that for a local interface (with the local keyword), the > IDL-generated class should already inherit from LocalObject: > > // IDL > local interface LocalIF { > void an_op (in long an_arg); > }; > > // C++ > class MyLocalIF : public LocalIF { > // same as above > }; > > I think that providing a local implementation for a non-local > interface > (as in pseudo IDL) should be out of scope of the C++ mapping, we have > well-defined mechanisms in the POA for that. > > Frank > > X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Received: from AMERWEST-EMS1.IONAGLOBAL.COM ([10.81.1.38]) by amereast-ems1.IONAGLOBAL.COM with Microsoft SMTPSVC(5.0.2195.4905); Thu, 29 Aug 2002 18:15:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Received: from dublin.emea.iona.com ([212.120.147.5]) by AMERWEST-EMS1.IONAGLOBAL.COM with Microsoft SMTPSVC(5.0.2195.2966); Thu, 29 Aug 2002 15:15:39 -0700 Received: from Resonate.com (gate1.Resonate.com [63.167.149.130]) by dublin.emea.iona.com (8.8.8/iona-1.02) with ESMTP id XAA22976 for ; Thu, 29 Aug 2002 23:15:37 +0100 (BST) Received: from butane-9.resonate.com (butane-9.resonate.com [192.168.73.9]) by Resonate.com (8.12.5/8.12.5) with ESMTP id g7TMFSdB021118; Thu, 29 Aug 2002 15:15:28 -0700 Received: from floorboard.com (localhost [127.0.0.1]) by butane-9.resonate.com (8.10.2+Sun/8.8.2) with ESMTP id g7TMFKN20379; Thu, 29 Aug 2002 15:15:20 -0700 (PDT) content-class: urn:content-classes:message Subject: Re: Issue 5579 [Was: Re: C++ revision] Date: Thu, 29 Aug 2002 17:15:20 -0500 Message-ID: <3D6E9CF8.9CA71B13@floorboard.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 5579 [Was: Re: C++ revision] Thread-Index: AcJPqZ3F4YmgwCSgSXqg99otbi2lUA== From: "Jonathan Biggar" To: "Normier, Bernhard" Cc: "Andrew Watson" , "Jishnu Mukerji" , , "triodia.com, michi" , "Linda Heaton" , "C++ Revision Task Force" "Normier, Bernhard" wrote: > > Hi Jonathan, > > > > (5579) will have to be declared urgent. > > > > Ok, I don't think it is a good idea for the RTF to let this get > > published and then have to immediately tweak it because we know there > > are some outstanding issues. > > My understanding is that the problematic part is the servant manager > implementation, which is not discussed by your proposal. That is another problematic part. Unless we decide that we have to solve it to avoid breaking code, the default of this proposal will be to allow code to break. > > So, unless there is an objection from the chair, I'd like to formally > > request that this issue be declared urgent. > > > > Here is my proposed resolution: > > > > 1. Remove _add_ref() and _remove_ref(), and declare that LocalObject > > handles its own reference counting internally. > > I'd like to keep these member functions, to allow different yet > portable ref counting implementation, such as no-op or with control > over the mutex used. I'm not convinced. I can't see any useful user defined ref counting functions that are portable. If there aren't any, then an ORB implementation can just provide a non-standard mixin class to change the refcounting behavior, which gives the user the same ability. > > 2. Add magic text that requires a pointer to a LocalObject to > > automatically convert to a _ptr. > > Ok. > > > > > Here is my proposed replacement text for 1.35: > > > > -------------------------------- > > 1.35 Local Object > > > > The C++ mapping of Local Object is a class derived from CORBA::Object > > that is used as a base class for locality constrained object > > implementations. A locality constrained object is implemented > > by a class > > derived both from the class mapping the interface and from > > CORBA::LocalObject. > > > > namespace CORBA > > { > > class LocalObject : public virtual Object > > { > > public: > > // ...other pseudo ops not shown... > > protected: > > LocalObject(); > > ~LocalObject(); > > }; > > }; > > > > Member functions and any data members needed to implement the Object > > pseudo-operations and any other ORB support functions shall also be > > supplied but are not shown. > > > > The implementation of LocalObject must provide a thread-safe mechanism > > for managing the lifecycle of a local object reference via > > _duplicate() > > and release(). The destructor of a local object implementation will > > automatically be called when the last reference to it has > > been released. > > I'm happy with a ref-counted thread-safe LocalObject implementation. > > > > > The IDL compiler will generate appropriate conversion operations to > > allow a pointer to a local object implementation to be automatically > > converted to the corresponding _ptr or _var type. > > > > Here is an example of how to implement a local interface: > > > > // IDL > > interface LocalIF { > > void an_op(in long an_arg); > > }; > > > > // C++ > > class MyLocalIF : public LocalIF, public CORBA::LocalObject { > > public: > > MyLocalIF(...); > > ~MyLocalIF(); > > > > void an_op(CORBA::Long an_arg); > > }; > > It would be nice to resolve issue #4496 with this resolution as > well. Issue #4496 suggests to have the abstract class generated > from interface LocalIF derive from CORBA::LocalObject. Hmmm, the suggested approach there conflicts with the idea of allowing local object implementations still be usable via POA mediated servants. Also, the issue states that the IDL compiler/ORB can't enforce the requirement to inherit from LocalObject, which is incorrect. All it needs to do is define a pure virtual function in either CORBA::Object or the generated interface class that is only satisfied if you also inherit from LocalObject. (For normal interfaces, the IDL compiler can generate the redefined virtual function itself.) Also, I don't think that allowing is_a("IDL:omg.org/CORBA/LocalObject:1.0") is a good idea. I don't think "IDL:omg.org/CORBA/LocalObject:1.0" even exists. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: "Pilhofer, Frank" To: "'Normier, Bernhard'" , cxx_revision@omg.org Subject: RE: Proposal for C++ local interface mapping (issue #5579) Date: Tue, 3 Dec 2002 14:07:03 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) > > > I suggest that for a local interface (with the local keyword), the > > IDL-generated class should already inherit from LocalObject: > > I think there is a consensus to reject such mapping > (suggested by issue #4496) (see attached e-mail). > Hi Bernhard, I rather object to Jonathan's proposal to allow POA mediated invocations for local objects. By declaring an interface as local, you're disallowing that possibility. You could argue that the type of implementation should not be influenced by the interface designer's choice, but then we wouldn't need the local keyword altogether. I think we can live with a mapping that disallows POA-mediation for local objects (declared via a local interface). > > I disagree. Since local implementations of both local and non > local interfaces are possible > I'm not so sure about that. If we disallow POA mediation for local objects, it would be consequent to disallow local implementations of a regular interface. It's not needed, anyway. If you want to provide a local implementation, then you can always derive a local interface: local interface MyNamingService : CosNaming::NamingContext {}; since a local interface is allowed to inherit a regular interface. This inheritance needs not to be known to the user of that reference. As for Jon's last comment, there is an IDL:omg.org/CORBA/LocalBase:1.0 Repository Id (page 10-42 in CORBA 3 in the LocalInterfaceDef section), so _is_a on a Local Object using this Id must return true (or that paragraph needs to be changed). Frank Subject: RE: Proposal for C++ local interface mapping (issue #5579) Date: Tue, 3 Dec 2002 14:34:34 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for C++ local interface mapping (issue #5579) Thread-Index: AcKa/y82qXw4aEJUQvS7f35NwFhOcQAAVn0w From: "Normier, Bernhard" To: "Pilhofer, Frank" , X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id gB3JY0324060 Hi Frank, A debate on #4496 would certainly be useful ... I can be convinced either way. I don't see how this has anything to do with POA-based implementations; to provide a POA-based implementation (servant), you need to derive from generated skeletons. Naturally a local implementation (achieved through derivation) is not mediated by anything. One advantage of the current mapping (the generated class for local object does not derive from CORBA::LocalObject) is that it's implemented by a number of products (such as Orbix), and works well. On the second point I don't understand your objection. Providing local implementations of regular interfaces is useful; having to declare a dummy local interface to be able to do so would be rather user-unfriendly. Cheers, Bernard > -----Original Message----- > From: Pilhofer, Frank [mailto:fpilhofe@mc.com] > Sent: Tuesday, December 03, 2002 2:07 PM > To: Normier, Bernhard; cxx_revision@omg.org > Subject: RE: Proposal for C++ local interface mapping (issue #5579) > > > > > > > I suggest that for a local interface (with the local keyword), the > > > IDL-generated class should already inherit from LocalObject: > > > > I think there is a consensus to reject such mapping > > (suggested by issue #4496) (see attached e-mail). > > > > Hi Bernhard, > > I rather object to Jonathan's proposal to allow POA mediated > invocations > for local objects. By declaring an interface as local, you're > disallowing > that possibility. You could argue that the type of > implementation should not > be influenced by the interface designer's choice, but then we > wouldn't need > the local keyword altogether. > > I think we can live with a mapping that disallows > POA-mediation for local > objects (declared via a local interface). > > > > > I disagree. Since local implementations of both local and non > > local interfaces are possible > > > > I'm not so sure about that. If we disallow POA mediation for local > objects, it would be consequent to disallow local implementations of > a regular interface. It's not needed, anyway. If you want to provide > a local implementation, then you can always derive a local interface: > > local interface MyNamingService : CosNaming::NamingContext {}; > > since a local interface is allowed to inherit a regular > interface. This > inheritance needs not to be known to the user of that reference. > > As for Jon's last comment, there is an IDL:omg.org/CORBA/LocalBase:1.0 > Repository Id (page 10-42 in CORBA 3 in the LocalInterfaceDef > section), > so _is_a on a Local Object using this Id must return true (or that > paragraph needs to be changed). > > Frank > X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Dec 2002 15:41:50 -0500 To: cxx_revision@omg.org From: Bill Beckwith Subject: RE: Proposal for C++ local interface mapping (issue #5579) Cc: andrew@omg.org [As a point of order mapping local interfaces to C++ is a major change and requires an RFP.] At 02:07 PM 12/3/2002, Pilhofer, Frank wrote: > >I rather object to Jonathan's proposal to allow POA mediated invocations >for local objects. By declaring an interface as local, you're disallowing >that possibility. You could argue that the type of implementation should not >be influenced by the interface designer's choice, but then we wouldn't need >the local keyword altogether. I couldn't agree more. The origin of local interfaces came from the desire to limit the amount of PIDL that exists. Thus I think the local interface mapping to C++ should be kept simple, clean, and small. >I think we can live with a mapping that disallows POA-mediation for local >objects (declared via a local interface). I think we must disallow POA-mediation for invocations to implementations of local interfaces. Otherwise how will we ever be able to use local interfaces in the POA specification. Implementations of non-local interfaces (servants) that happen to be in the same address space as the invoking thread are an entirely different matter. I'll refer to these implementations as co-located servants to avoid confusion. >> I disagree. Since local implementations of both local and non >> local interfaces are possible There is a HUGE difference between a co-located servant and a local interface implementation object. It would help if in discussing this topic we could use better nomenclature. >I'm not so sure about that. If we disallow POA mediation for local >objects, it would be consequent to disallow local implementations of >a regular interface. I also agree with this. It makes the language mappings simpler and cleaner. Bill Subject: RE: Proposal for C++ local interface mapping (issue #5579) Date: Tue, 3 Dec 2002 15:59:28 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for C++ local interface mapping (issue #5579) Thread-Index: AcKbDKIEMV19x+VrSUGQAmnzhMUmvQAAhBmg From: "Normier, Bernhard" To: "Bill Beckwith" , Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id gB3Kww326014 Hi Bill, The mapping of local interfaces to C++ (although somewhat incomplete) was part of the Components spec. Cheers, Bernard > -----Original Message----- > From: Bill Beckwith [mailto:bill.beckwith@ois.com] > Sent: Tuesday, December 03, 2002 3:42 PM > To: cxx_revision@omg.org > Cc: andrew@omg.org > Subject: RE: Proposal for C++ local interface mapping (issue #5579) > > > [As a point of order mapping local interfaces to C++ is > a major change and requires an RFP.] > > At 02:07 PM 12/3/2002, Pilhofer, Frank wrote: > > > >I rather object to Jonathan's proposal to allow POA mediated > invocations > >for local objects. By declaring an interface as local, > you're disallowing > >that possibility. You could argue that the type of > implementation should not > >be influenced by the interface designer's choice, but then > we wouldn't need > >the local keyword altogether. > > I couldn't agree more. The origin of local interfaces came from the > desire to limit the amount of PIDL that exists. > > Thus I think the local interface mapping to C++ should be kept > simple, clean, and small. > > >I think we can live with a mapping that disallows > POA-mediation for local > >objects (declared via a local interface). > > I think we must disallow POA-mediation for invocations to > implementations > of local interfaces. Otherwise how will we ever be able to use local > interfaces in the POA specification. > > Implementations of non-local interfaces (servants) that happen to be > in the same address space as the invoking thread are an entirely > different matter. I'll refer to these implementations as co-located > servants to avoid confusion. > > >> I disagree. Since local implementations of both local and non > >> local interfaces are possible > > There is a HUGE difference between a co-located servant and a local > interface implementation object. It would help if in discussing > this topic we could use better nomenclature. > > >I'm not so sure about that. If we disallow POA mediation for local > >objects, it would be consequent to disallow local implementations of > >a regular interface. > > I also agree with this. It makes the language mappings > simpler and cleaner. > > Bill > > > X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Dec 2002 16:16:01 -0500 To: "Normier, Bernhard" From: Bill Beckwith Subject: RE: Proposal for C++ local interface mapping (issue #5579) Cc: , At 03:59 PM 12/3/2002, Normier, Bernhard wrote: > >The mapping of local interfaces to C++ (although somewhat >incomplete) was part of the Components spec. Hi Bernhard, The proposals under discussion are all significant extensions to what was proposed in the Components spec. Best regards, Bill From: "Pilhofer, Frank" To: "'Normier, Bernhard'" , Bill Beckwith , cxx_revision@omg.org Subject: RE: Proposal for C++ local interface mapping (issue #5579) Date: Tue, 3 Dec 2002 16:17:50 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) > > The mapping of local interfaces to C++ (although somewhat > incomplete) was part of the Components spec. > No, it's not. The Components spec maps components to local interfaces. It then relies on the language mappings for the how-to of implementing them. Frank Subject: RE: Proposal for C++ local interface mapping (issue #5579) Date: Tue, 3 Dec 2002 16:26:01 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for C++ local interface mapping (issue #5579) Thread-Index: AcKbEXY0gWc3ZHn6QbKIFxflpYVLpQAAG1EA From: "Normier, Bernhard" To: "Pilhofer, Frank" , "Bill Beckwith" , X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id gB3LPU326686 Hi Frank, Please read the (adopted) components submission, document orbos/99-07-01, page 4-47 and 4-48. Regards, Bernard > -----Original Message----- > From: Pilhofer, Frank [mailto:fpilhofe@mc.com] > Sent: Tuesday, December 03, 2002 4:18 PM > To: Normier, Bernhard; Bill Beckwith; cxx_revision@omg.org > Subject: RE: Proposal for C++ local interface mapping (issue #5579) > > > > > > The mapping of local interfaces to C++ (although somewhat > > incomplete) was part of the Components spec. > > > > No, it's not. The Components spec maps components to local interfaces. > It then relies on the language mappings for the how-to of implementing > them. > > Frank > From: "Pilhofer, Frank" To: "'Normier, Bernhard'" , cxx_revision@omg.org Subject: RE: Proposal for C++ local interface mapping (issue #5579) Date: Tue, 3 Dec 2002 16:35:47 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) > > Please read the (adopted) components submission, document > orbos/99-07-01, page 4-47 and 4-48. > Hi Bernard, the FTF decided not to supply concrete language mappings and to provide a generic mapping to local interfaces instead. It was felt that this was a much cleaner solution; this way, CCM does not need to concern itself with numerous languages (and vice versa). Please see the updated ("available") specification formal/2002-06-65 at http://www.omg.org/technology/documents/formal/components.htm Frank Date: Tue, 03 Dec 2002 16:40:41 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: "Normier, Bernhard" Cc: "Pilhofer, Frank" , Bill Beckwith , cxx_revision@omg.org Subject: Re: Proposal for C++ local interface mapping (issue #5579) "Normier, Bernhard" wrote: > > Hi Frank, > > Please read the (adopted) components submission, document > orbos/99-07-01, page 4-47 and 4-48. > > Regards, > Bernard The right base document to use for the purposes of this discussion is: http://doc.omg.org/ptc/02-08-08 The precise text relevant to this discussion has also been made availabel as the following document by Andrew: http://doc.omg.org/ptc/02-08-06 This is excerpted from the message sent by Andrew Watson on 8/23/02. I am excerpting the entire messsage below for those that have been out of touch Jishnu. ______________________________________________________________________ Andrew's message: Jishnu, You wrote: > There is also this minor matter of which is the base document that we > are working with. I suspect it is ptc/02-01-26 together with the Section > 1.35 that was adopted as part of the Components adoption process > inserted into ptc/02-01-26 at an appropriate place, like as section > 1.35? We should perhaps create a fixed up base document to avoid > confusion. Since the Local Object mapping text is part of an adopted OMG spec (CCM), and Local Objects have already been added to published versions of CORBA 2.x, adding this "lost" text back into the C++ mapping spec is actually an editorial issue. Even if it's broken, it should be there until the RTF fixes it. I've therefore editorially created a version of ptc/02-01-26 (the final C++ chapter delivered by the last C++ RTF in April 2002) with the lost Local Object mapping text added back. This new document is ptc/02-08-08, and should be used as the basis for any revision of the C++ Local Object mapping. http://doc.omg.org/ptc/02-08-08 C++ mapping with CCM local object text The lost Local Object Mapping text is also available as ptc/02-08-06 - this is the document that Jishnu circulated by email a few days ago. http://doc.omg.org/ptc/02-08-06 Stand-alone CCM local object text Of course, there is a potential problem with this Local Object mapping - it breaks servant manager implementations because they are currently ordinary servants. The RTF has to decide if this really is a problem, and if it is, how to fix it. Steve Vinoski's proposed update to the Local Object mapping section is available as ptc/02-08-07. http://doc.omg.org/ptc/02-08-06 Steve's proposed local object mapping To help Juergen keep track of this issue, please put the issue number (5579) in the subject line of messages about it. By default, the next published version of the C++ mapping WILL INCLUDE the CCM local object mapping. If the RTF wants to change this adopted text now, rather than wait until the RTF publishes its report in Feb 2003, this issue (5579) will have to be declared urgent. Date: Tue, 03 Dec 2002 16:46:14 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: "Pilhofer, Frank" Cc: "'Normier, Bernhard'" , Bill Beckwith , cxx_revision@omg.org Subject: Re: Proposal for C++ local interface mapping (issue #5579) "Pilhofer, Frank" wrote: > > > > > The mapping of local interfaces to C++ (although somewhat > > incomplete) was part of the Components spec. > > > > No, it's not. The Components spec maps components to local interfaces. > It then relies on the language mappings for the how-to of implementing > them. Sorry, that is half the story. The other half of the story is that the Component spec as adopted also contained text describing the mapping of local objects to C++. A look at the following documents might convince you of that fact: Relevant adopted specification: http://doc.omg.org/orbos/99-07-01 page 4-47 and 4-48 The updated C++ Mapping chapter: http://doc.omg.org/ptc/02-08-08 The relevant text excerpted: http://doc.omg.org/ptc/02-08-06 The text does contain a bit of ambiguity and wiggle room Jishnu. Date: Tue, 03 Dec 2002 16:48:45 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: "Pilhofer, Frank" Cc: "'Normier, Bernhard'" , cxx_revision@omg.org Subject: Re: Proposal for C++ local interface mapping (issue #5579) "Pilhofer, Frank" wrote: > > > > > Please read the (adopted) components submission, document > > orbos/99-07-01, page 4-47 and 4-48. > > > > Hi Bernard, > > the FTF decided not to supply concrete language mappings and to provide > a generic mapping to local interfaces instead. It was felt that this was > a much cleaner solution; this way, CCM does not need to concern itself > with numerous languages (and vice versa). > > Please see the updated ("available") specification formal/2002-06-65 at > http://www.omg.org/technology/documents/formal/components.htm > > Frank Frank, this was resolved by an earlier round of FTF and it is already part of published or ready to publish specifications, so it is not really open to negotiations. The local object part was finalized and incorporated in the Core long before the final FTF report and once it was included in Core and published as a formal specification, the FTF really did not have any control over that part of it anymore. Jishnu. Date: Tue, 03 Dec 2002 16:22:32 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Bill Beckwith Cc: cxx_revision@omg.org, andrew@omg.org Subject: Re: Proposal for C++ local interface mapping (issue #5579) Bill Beckwith wrote: > > [As a point of order mapping local interfaces to C++ is > a major change and requires an RFP.] Sorry Bill, I think you misunderstand the current state of affairs. Local Interfaces are already mapped to C++ as per the adopted Components Specification, and the updated C++ mapping standard can be found at: http://doc.omg.org/ptc/02-08-08 All that the RTF is trying to do is fix the incompleteness/buggyness of the adopted specification, which is what RTFs are supposed to do. BTW, the adopted text related to C++ mapping of Loca Objects clearly states: "The C++ mapping of Local Object is a class derived from CORBA::Object that is used as a base class for locality constrained object implementations. A locality constrained object is implemented by a class derived both from the class mapping the interface and from CORBA::LocalObject." So we have to agree upong whether the inheritnce tree looks like: 1. Jon's proposal: // C++ class LocalIF { ... } // IDL compiler generated class MyLocalIF : public LocalIF, public CORBA::LocalObject { ... } or 2. Other apparent proposal: // C++ class LocalIF : CORBA::LocalObject {....} // IDL compiler generated class MyLocalIF : public LocalIF { .... } Unfortunately the language used in the adopted spec appears to admit both of the possibilities enumerated above. We should choose one after weighing the pros and cons of that choice. W should also keep in mind that (I believe) that the original intent of the submitters of the Component Specification's Local Interface portion was always to allow local implementation of non-local interfaces as a means for moving all the locality constrained interfaces to local interfaces relatively painlessly without unnecessarily breaking code. So I don't think tha a general position stating that "providing a local implementation for a non-local interface (as in pseudo IDL) should be out of scope of the C++ mapping" is not sustainable based on the history of development of this feature. The bottom line is, it would be very appropriate to limit the activities of the RTF to fixing the problems with the adopted specification and refraining from doing a ground up redesign of the same. Jishnu. X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Dec 2002 22:26:10 -0500 To: Jishnu Mukerji From: Bill Beckwith Subject: Re: Proposal for C++ local interface mapping (issue #5579) Cc: cxx_revision@omg.org, andrew@omg.org At 04:22 PM 12/3/2002, Jishnu Mukerji wrote: > > >Bill Beckwith wrote: >> >> [As a point of order mapping local interfaces to C++ is >> a major change and requires an RFP.] > >Sorry Bill, I think you misunderstand the current state of affairs. I am well aware of the extent of the current mapping of local interfaces to C++. >Local Interfaces are already mapped to C++ as per the adopted Components >Specification, and the updated C++ mapping standard can be found at: > > http://doc.omg.org/ptc/02-08-08 As you mention below, the current local interface mapping does not specify the semantics for implementations of local interfaces other than: A locality constrained object is implemented by a class derived both from the class mapping the interface and from CORBA::LocalObject. >All that the RTF is trying to do is fix the incompleteness/buggyness of >the adopted specification, which is what RTFs are supposed to do. What you are calling an "incomplete" specification is one that gave several embedded ORBs the freedom to provide very lightweight local interface mappings. Given the strong popularity of CORBA in embedded systems these days it would be a shame to unnecessarily bloat these embedded ORBs and user authors of local interfaces. Thus I don't consider the existing specification broken in this particular regard. >BTW, the adopted text related to C++ mapping of Loca Objects clearly >states: > >"The C++ mapping of Local Object is a class derived from >CORBA::Object >that is used as a base class for locality constrained object >implementations. A locality constrained object is implemented by a >class >derived both from the class mapping the interface and from >CORBA::LocalObject." Yes, it does. And the LocalIF class in your examples below satisfies the requirements of a "derived both from the class mapping the interface and from CORBA::LocalObject" >So we have to agree upong whether the inheritnce tree looks like: > >1. Jon's proposal: > >// C++ > class LocalIF { ... } // IDL compiler generated > > class MyLocalIF : public LocalIF, public CORBA::LocalObject { ... } Jon probably meant to make these virtual inheritance. >or 2. Other apparent proposal: > >// C++ > class LocalIF : CORBA::LocalObject {....} // IDL compiler generated > > class MyLocalIF : public LocalIF { .... } Here no virtual inheritance is required (which is a very good thing). There is also a third option where LocalIF is generated in such a way that a user can provide the operation implementations: IDL compiler: class LocalIF : public CORBA::LocalObject { virtual void op1(); } User writes: void LocalIF::op1() { // ... } Note that to the client of a local interface approaches (1), (2), and (3) all are code compatible. There are implementation differences for someone providing a local interface. But the specification doesn't fill provide those semantics. It is adding those semantics that I believe is a significant change. My preference (in order of decreasing preference): (A) constraint the spec to (3) (B) leave the spec so that it allows either (1), (2), or (3) (C) constraining the spec to (2) Unfortunately I fear that (A) and (C) may be out of scope for an RTF. >Unfortunately the language used in the adopted spec appears to admit >both of the possibilities enumerated above. We should choose one >after >weighing the pros and cons of that choice. Agreed. >We should also keep in mind that (I believe) that the original intent of >the submitters of the Component Specification's Local Interface portion >was always to allow local implementation of non-local interfaces as a >means for moving all the locality constrained interfaces to local >interfaces relatively painlessly without unnecessarily breaking code. So >I don't think tha a general position stating that "providing a local >implementation for a non-local interface (as in pseudo IDL) should be >out of scope of the C++ mapping" is not sustainable based on the history >of development of this feature. I may be mincing words here with you but I'm not saying that extending the semantics of local interface implementations is out of scope for the C++ mapping. I am saying that it is out of scope for the C++ RTF. This needs to be done in an RFP submission. >The bottom line is, it would be very appropriate to limit the activities >of the RTF to fixing the problems with the adopted specification and >refraining from doing a ground up redesign of the same. I agree. Incremental fixes to existing semantics are appropriate. Wholesale changes or extensions of the spec are inappropriate. And since the ambiguities of the existing spec allowed the optimization of existing implementations we should be careful not to plunder those optimizations. If a change does this, however minor the change appears, the change should definitely be considered a major specification change. Bill Date: Wed, 04 Dec 2002 10:53:58 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Bill Beckwith Cc: cxx_revision@omg.org, andrew@omg.org Subject: Re: Proposal for C++ local interface mapping (issue #5579) Bill Beckwith wrote: > > At 04:22 PM 12/3/2002, Jishnu Mukerji wrote: > > > > > >Bill Beckwith wrote: > >> > >> [As a point of order mapping local interfaces to C++ is > >> a major change and requires an RFP.] > > > >Sorry Bill, I think you misunderstand the current state of affairs. > > I am well aware of the extent of the current mapping of local > interfaces to C++. I am sorry for missinterpreting your statement above. Now I understand what you meant. Please accept my aplogies for alleging that you were unaware or misinformed. > >All that the RTF is trying to do is fix the incompleteness/buggyness of > >the adopted specification, which is what RTFs are supposed to do. > > What you are calling an "incomplete" specification is one that > gave several embedded ORBs the freedom to provide very lightweight > local interface mappings. Given the strong popularity of CORBA in > embedded systems these days it would be a shame to unnecessarily > bloat these embedded ORBs and user authors of local interfaces. > > Thus I don't consider the existing specification broken in this > particular regard. Voting processes in RTFs and ABs and TCs exist for resolving such disagreements. > > >BTW, the adopted text related to C++ mapping of Loca Objects clearly > >states: > > > >"The C++ mapping of Local Object is a class derived from CORBA::Object > >that is used as a base class for locality constrained object > >implementations. A locality constrained object is implemented by a class > >derived both from the class mapping the interface and from > >CORBA::LocalObject." > > Yes, it does. And the LocalIF class in your examples below > satisfies the requirements of a "derived both from the class mapping > the interface and from CORBA::LocalObject" > > >So we have to agree upong whether the inheritnce tree looks like: > > > >1. Jon's proposal: > > > >// C++ > > class LocalIF { ... } // IDL compiler generated > > > > class MyLocalIF : public LocalIF, public CORBA::LocalObject { ... } > > Jon probably meant to make these virtual inheritance. > > >or 2. Other apparent proposal: > > > >// C++ > > class LocalIF : CORBA::LocalObject {....} // IDL compiler generated > > > > class MyLocalIF : public LocalIF { .... } > > Here no virtual inheritance is required (which is a > very good thing). > > There is also a third option where LocalIF is generated in such a way > that a user can provide the operation implementations: > > IDL compiler: > > class LocalIF : public CORBA::LocalObject > { > virtual void op1(); > } > > User writes: > > void LocalIF::op1() > { > // ... > } Strictly speaking this is inconsistent with the sentence: "A locality constrained object is implemented by a class derived both from the class mapping the interface and from CORBA::LocalObject." Since there is no class here that is derived from both CORBA::LocalObject and LocalIF. You could bring this into alignment with the specification by reverting back to (2), and leaving the option open for the compiler to generate the MuLocalIF class, and let the users write just the "void MyLocalIF::op1(){...} etc. That may be the best possible compromise thing to go for. Lets call this 2a for now. > Note that to the client of a local interface approaches > (1), (2), and (3) all are code compatible. There are > implementation differences for someone providing a local > interface. But the specification doesn't fill provide > those semantics. It is adding those semantics that I > believe is a significant change. > > My preference (in order of decreasing preference): > > (A) constraint the spec to (3) > (B) leave the spec so that it allows either (1), (2), or (3) > (C) constraining the spec to (2) > > Unfortunately I fear that (A) and (C) may be out of scope > for an RTF. There is an additional possibility: (D) allow either (1) or (2) (and 2a) but state clearly how they are done. This IMHO is an important option since I believe (3) is inconsistent with the language in the current specification and hence is out of scope by the rules that you appear to have exponded and that I tend to agree with. I don't believe that (C) is necessarily out of scope. We have made more significant changes in the past in RTFs. Now whether that is a good thing or a bad thing is something worth discussing. But ultimately what is or is not out of scope is determined mainly by taking votes in RTFs and AB. I also believe that (D) is within scope. I don't believe (B) is in scope because (B) is actually already out of scope since (3) is inconsistent with the ambiguous specification. > >Unfortunately the language used in the adopted spec appears to admit > >both of the possibilities enumerated above. We should choose one after > >weighing the pros and cons of that choice. > > Agreed. > > >We should also keep in mind that (I believe) that the original intent of > >the submitters of the Component Specification's Local Interface portion > >was always to allow local implementation of non-local interfaces as a > >means for moving all the locality constrained interfaces to local > >interfaces relatively painlessly without unnecessarily breaking code. So > >I don't think tha a general position stating that "providing a local > >implementation for a non-local interface (as in pseudo IDL) should be > >out of scope of the C++ mapping" is not sustainable based on the history > >of development of this feature. > > I may be mincing words here with you but I'm not saying that extending > the semantics of local interface implementations is out of scope for the > C++ mapping. I am saying that it is out of scope for the C++ RTF. > This needs to be done in an RFP submission. OK, I understand your opinion. However, I think for the sake of timely availability of an unambiguous standard we should try very hard to avoid the RFP route. Once you open the RFP barn-gate having lived through the last two rounds of C++ mapping RFPs I don't think you will arrive at a closure on it before the end of this decade, which IMHO won't be a good thing. > >The bottom line is, it would be very appropriate to limit the activities > >of the RTF to fixing the problems with the adopted specification and > >refraining from doing a ground up redesign of the same. > > I agree. Incremental fixes to existing semantics are appropriate. > Wholesale changes or extensions of the spec are inappropriate. > > And since the ambiguities of the existing spec allowed the optimization > of existing implementations we should be careful not to plunder those > optimizations. If a change does this, however minor the change appears, > the change should definitely be considered a major specification change. I agree that any changes/clarifications should take into consideration implementations that are out in the field that are consistent with the specification as it exists. As long as it stays within those guidelines I don't see why the RTF cannot handle this. Jishnu. Subject: RE: Proposal for C++ local interface mapping (issue #5579) Date: Wed, 4 Dec 2002 14:51:55 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for C++ local interface mapping (issue #5579) Thread-Index: AcKbRh2GC89VAJfSSTKBAx5wU2GM4gAhCpbw From: "Normier, Bernhard" To: "Bill Beckwith" , "Jishnu Mukerji" Cc: , X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id gB4Jpc317526 Hi Bill, As chair of this RTF, I am trying to get a number of open issues resolved. There are many open issues related to Local Interfaces, and a number of people consider their resolution rather urgent. A possible resolution for some issue can be that it's outside of the scope of an RTF ... but like Jishnu I fear this would mean several years before any resolution. Now, on how to implement local interfaces in C++. I'd be very wary of allowing several implementations: this would make the mapping complicated, introduce the risk that vendors would not support all of them ... and then no portability of implementation. Looking at mapping (1) [generated class does not derive from LocalObject], (2) [generated class derives from LocalObject], and (3) [only a partial class gets generated that the user fills in], my least favorite is (3): - typically a class implementation has data members; I doubt we could specify a portable way to add data members to a partially generated class. - the C++ mapping already deals with two similar issues (how to implement POA servants, how to implement value types) through entirely generated base classes that the user derives from to provide implementations. Regarding (1) and (2), whether or not the sometimes costly virtual inheritance is required is a reasonable criteria. But I think it's actually the opposite to what you presented: (1) does not require virtual inheritance while (2) does. Say we have: interface A {}; interface B {}; interface C : A, B {} With (2), if the derivation from CORBA::LocalObject is non virtual, we would get: class A : public CORBA::LocalObject { ... }; class B : public CORBA::LocalObject { ... }; class C : public virtual A, public virtual B { ... }; Unfortunately we get two LocalObjects in every C instance. Since the IDL compiler can't anticipate future derivation, the only safe mapping is to generate virtual derivation from LocalObject: class A : public virtual CORBA::LocalObject { ... }; etc. With (1), it's up to the user to use or not to use virtual inheritance. AImpl and BImpl could be: class AImpl: public A, public CORBA::LocalObject { ... }; class BImpl: public B, public CORBA::LocalObject { ... }; With such AImpl and BImpl, it would not be possible to write a CImpl that simply derives from both AImpl and BImpl (we'd get two LocalObjects) ... but that's the user problem. He can switch to virtual inheritance if we wants such multiple inheritance reuse. Best regards, Bernard > -----Original Message----- > From: Bill Beckwith [mailto:bill.beckwith@ois.com] > Sent: Tuesday, December 03, 2002 10:26 PM > To: Jishnu Mukerji > Cc: cxx_revision@omg.org; andrew@omg.org > Subject: Re: Proposal for C++ local interface mapping (issue #5579) > > > At 04:22 PM 12/3/2002, Jishnu Mukerji wrote: > > > > > >Bill Beckwith wrote: > >> > >> [As a point of order mapping local interfaces to C++ is > >> a major change and requires an RFP.] > > > >Sorry Bill, I think you misunderstand the current state of affairs. > > I am well aware of the extent of the current mapping of local > interfaces to C++. > > >Local Interfaces are already mapped to C++ as per the > adopted Components > >Specification, and the updated C++ mapping standard can be found at: > > > > http://doc.omg.org/ptc/02-08-08 > > As you mention below, the current local interface mapping does > not specify the semantics for implementations of local interfaces > other than: > > A locality constrained object is implemented by a class derived > both from the class mapping the interface and from > CORBA::LocalObject. > > >All that the RTF is trying to do is fix the > incompleteness/buggyness of > >the adopted specification, which is what RTFs are supposed to do. > > What you are calling an "incomplete" specification is one that > gave several embedded ORBs the freedom to provide very lightweight > local interface mappings. Given the strong popularity of CORBA in > embedded systems these days it would be a shame to unnecessarily > bloat these embedded ORBs and user authors of local interfaces. > > Thus I don't consider the existing specification broken in this > particular regard. > > >BTW, the adopted text related to C++ mapping of Loca Objects clearly > >states: > > > >"The C++ mapping of Local Object is a class derived from > CORBA::Object > >that is used as a base class for locality constrained object > >implementations. A locality constrained object is > implemented by a class > >derived both from the class mapping the interface and from > >CORBA::LocalObject." > > Yes, it does. And the LocalIF class in your examples below > satisfies the requirements of a "derived both from the class mapping > the interface and from CORBA::LocalObject" > > >So we have to agree upong whether the inheritnce tree looks like: > > > >1. Jon's proposal: > > > >// C++ > > class LocalIF { ... } // IDL compiler generated > > > > class MyLocalIF : public LocalIF, public CORBA::LocalObject { ... } > > Jon probably meant to make these virtual inheritance. > > >or 2. Other apparent proposal: > > > >// C++ > > class LocalIF : CORBA::LocalObject {....} // IDL compiler generated > > > > class MyLocalIF : public LocalIF { .... } > > Here no virtual inheritance is required (which is a > very good thing). > > There is also a third option where LocalIF is generated in such a way > that a user can provide the operation implementations: > > IDL compiler: > > class LocalIF : public CORBA::LocalObject > { > virtual void op1(); > } > > User writes: > > void LocalIF::op1() > { > // ... > } > > Note that to the client of a local interface approaches > (1), (2), and (3) all are code compatible. There are > implementation differences for someone providing a local > interface. But the specification doesn't fill provide > those semantics. It is adding those semantics that I > believe is a significant change. > > My preference (in order of decreasing preference): > > (A) constraint the spec to (3) > (B) leave the spec so that it allows either (1), (2), or (3) > (C) constraining the spec to (2) > > Unfortunately I fear that (A) and (C) may be out of scope > for an RTF. > > >Unfortunately the language used in the adopted spec appears to admit > >both of the possibilities enumerated above. We should choose > one after > >weighing the pros and cons of that choice. > > Agreed. > > >We should also keep in mind that (I believe) that the > original intent of > >the submitters of the Component Specification's Local > Interface portion > >was always to allow local implementation of non-local interfaces as a > >means for moving all the locality constrained interfaces to local > >interfaces relatively painlessly without unnecessarily > breaking code. So > >I don't think tha a general position stating that "providing a local > >implementation for a non-local interface (as in pseudo IDL) should be > >out of scope of the C++ mapping" is not sustainable based on > the history > >of development of this feature. > > I may be mincing words here with you but I'm not saying that extending > the semantics of local interface implementations is out of > scope for the > C++ mapping. I am saying that it is out of scope for the C++ RTF. > This needs to be done in an RFP submission. > > >The bottom line is, it would be very appropriate to limit > the activities > >of the RTF to fixing the problems with the adopted specification and > >refraining from doing a ground up redesign of the same. > > I agree. Incremental fixes to existing semantics are appropriate. > Wholesale changes or extensions of the spec are inappropriate. > > And since the ambiguities of the existing spec allowed the > optimization > of existing implementations we should be careful not to plunder those > optimizations. If a change does this, however minor the > change appears, > the change should definitely be considered a major > specification change. > > Bill > > > X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Dec 2002 16:02:28 -0500 To: Jishnu Mukerji From: Bill Beckwith Subject: Re: Proposal for C++ local interface mapping (issue #5579) Cc: cxx_revision@omg.org, andrew@omg.org, soley@omg.org At 10:53 AM 12/4/2002, Jishnu Mukerji wrote: > > >Bill Beckwith wrote: >> >> At 04:22 PM 12/3/2002, Jishnu Mukerji wrote: >> > >> > >> >Bill Beckwith wrote: >> Thus I don't consider the existing specification broken in this >> particular regard. > >Voting processes in RTFs and ABs and TCs exist for resolving such >disagreements. ... as long as the change is not "major". The RFP submission process is appropriate for major changes. >> There is also a third option where LocalIF is generated in such a way >> that a user can provide the operation implementations: >> >> IDL compiler: >> >> class LocalIF : public CORBA::LocalObject >> { >> virtual void op1(); >> } >> >> User writes: >> >> void LocalIF::op1() >> { >> // ... >> } > >Strictly speaking this is inconsistent with the sentence: > >"A locality constrained object is implemented by a class derived both >from the class mapping the interface and from CORBA::LocalObject." > >Since there is no class here that is derived from both >CORBA::LocalObject and LocalIF. You could bring this into alignment with >the specification by reverting back to (2), and leaving the option open >for the compiler to generate the MuLocalIF class, and let the users >write just the "void MyLocalIF::op1(){...} etc. That may be the best >possible compromise thing to go for. Lets call this 2a for now. Do you have a valid technical justification for precluding LocalIF as the implementation class? Saying that LocalIF isn't derived from LocalIF seems like splitting hairs to me. >> Note that to the client of a local interface approaches >> (1), (2), and (3) all are code compatible. There are >> implementation differences for someone providing a local >> interface. But the specification doesn't fill provide >> those semantics. It is adding those semantics that I >> believe is a significant change. >> >> My preference (in order of decreasing preference): >> >> (A) constraint the spec to (3) >> (B) leave the spec so that it allows either (1), (2), or (3) >> (C) constraining the spec to (2) >> >> Unfortunately I fear that (A) and (C) may be out of scope >> for an RTF. > >There is an additional possibility: > >(D) allow either (1) or (2) (and 2a) but state clearly how they are >done. This IMHO is an important option since I believe (3) is >inconsistent with the language in the current specification and hence is >out of scope by the rules that you appear to have exponded and that I >tend to agree with. As I've implied, I don't like (1). >I don't believe that (C) is necessarily out of scope. We have made more >significant changes in the past in RTFs. Now whether that is a good >thing or a bad thing is something worth discussing. But ultimately what >is or is not out of scope is determined mainly by taking votes in RTFs >and AB. In my experiences an OMG staff member (Andrew) determines what is in scope. Asking an RTF to determine what is in its own scope would is folly IMO. >I also believe that (D) is within scope. I don't believe (B) is in scope >because (B) is actually already out of scope since (3) is inconsistent >with the ambiguous specification. On this we disagree. >> I may be mincing words here with you but I'm not saying that extending >> the semantics of local interface implementations is out of scope for the >> C++ mapping. I am saying that it is out of scope for the C++ RTF. >> This needs to be done in an RFP submission. > >OK, I understand your opinion. However, I think for the sake of timely >availability of an unambiguous standard we should try very hard to avoid >the RFP route. There are many places where OMG specs are intentionally ambiguous in order to accommodate different implementations. These are frequently the result of long fought debates in RFP submission groups. Thus I don't believe that ambiguity is sufficient justification for altering good process (ie. an RFP). >Once you open the RFP barn-gate having lived through the >last two rounds of C++ mapping RFPs I don't think you will arrive at >a >closure on it before the end of this decade, which IMHO won't be a >good >thing. You can scope the RFP. This has been done for other language mappings with success in the past. >> And since the ambiguities of the existing spec allowed the optimization >> of existing implementations we should be careful not to plunder those >> optimizations. If a change does this, however minor the change appears, >> the change should definitely be considered a major specification change. > >I agree that any changes/clarifications should take into consideration >implementations that are out in the field that are consistent with the >specification as it exists. As long as it stays within those guidelines >I don't see why the RTF cannot handle this. It is very challenging to trim the code size of huge amount of crud that this and other OMG specs puts into CORBA. If you aren't more workable on this _one_ issue you will make CORBA in embedded systems impractical. I plead with you to think this through a bit more carefully. Bill X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Dec 2002 17:44:05 -0500 To: Jishnu Mukerji From: Bill Beckwith Subject: Re: Proposal for C++ local interface mapping (issue #5579) - Process Cc: cxx_revision@omg.org, andrew@omg.org, soley@omg.org (I split the process discussion and technical discussion into separate email threads so the emails are easier to parse.) At 04:53 PM 12/4/2002, Jishnu Mukerji wrote: >> It is very challenging to trim the code size of huge amount of crud that >> this and other OMG specs puts into CORBA. > >I am not the one that is suggesting producing an outcome of that sort. I >believe we can arrive at a very workable solution within the framework >of this RTF taking care of your concerns almost completely. but we can >do so only if we stop wasting time arguing about scope and first work >out a plausible solution and then ask questions about whether it is in >scope or not. O.K. I'll shut up about scope. >> If you aren't more workable on this _one_ issue you will make CORBA in >> embedded systems impractical. I plead with you to think this through >> a bit more carefully. > >Bill, so far it is not me that is "not workable" in this dicsussion, and >throwing around all this FUD about making CORBA embedded systems >impractical instead of discussing possible ways of working through the >issue is just a waste of everyone's time IMHO. I'm certainly not trying to waste anyone's time. This is a critical issue and I'm just trying to make sure that the existing text doesn't get changed without due consideration for embedded systems. Bill X-Sender: beckwb@192.168.10.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 04 Dec 2002 17:53:18 -0500 To: Jishnu Mukerji From: Bill Beckwith Subject: Re: Proposal for C++ local interface mapping (issue #5579) - Technical Cc: cxx_revision@omg.org, andrew@omg.org, soley@omg.org (I split the process discussion and technical discussion into separate email threads so the emails are easier to parse.) At 04:53 PM 12/4/2002, Jishnu Mukerji wrote: >> Saying that LocalIF isn't derived from LocalIF seems like splitting >> hairs to me. > >I agree. I was just playing the game using your rules.:-) O.K. >> >> Note that to the client of a local interface approaches >> >> (1), (2), and (3) all are code compatible. There are >> >> implementation differences for someone providing a local >> >> interface. But the specification doesn't fill provide >> >> those semantics. It is adding those semantics that I >> >> believe is a significant change. >> >> >> >> My preference (in order of decreasing preference): >> >> >> >> (A) constraint the spec to (3) >> >> (B) leave the spec so that it allows either (1), (2), or (3) >> >> (C) constraining the spec to (2) >> >> >> >> Unfortunately I fear that (A) and (C) may be out of scope >> >> for an RTF. >> > >> >There is an additional possibility: >> > >> >(D) allow either (1) or (2) (and 2a) but state clearly how they are >> >done. This IMHO is an important option since I believe (3) is >> >inconsistent with the language in the current specification and hence is >> >out of scope by the rules that you appear to have exponded and that I >> >tend to agree with. >> >> As I've implied, I don't like (1). > >OK, so we know that you will vote against that one.:-) I really should have said "I don't like _only_ (1)" since I support a solution that accommodates (1), (2), and (3). Bill Subject: RE: Proposal for C++ local interface mapping (issue #5579) Date: Mon, 9 Dec 2002 12:05:31 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for C++ local interface mapping (issue #5579) Thread-Index: AcKbRh2GC89VAJfSSTKBAx5wU2GM4gAhCpbwAPZzJ8A= From: "Normier, Bernhard" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id gB9H73302112 This time around I'd like to get a resolution to this local interface mapping issue, not let the discussion die. You can find my opinion in the e-mail below. If more people could provide their opinion, maybe a consensus or at least a majority could be found ... which would make a successful resolution more likely. Thanks, Bernard > -----Original Message----- > From: Normier, Bernhard > Sent: Wednesday, December 04, 2002 2:52 PM > To: Bill Beckwith; Jishnu Mukerji > Cc: cxx_revision@omg.org; andrew@omg.org > Subject: RE: Proposal for C++ local interface mapping (issue #5579) > > > Hi Bill, > > As chair of this RTF, I am trying to get a number of open > issues resolved. There are many open issues related to Local > Interfaces, and a number of people consider their resolution > rather urgent. > A possible resolution for some issue can be that it's outside > of the scope of an RTF ... but like Jishnu I fear this would > mean several years before any resolution. > > Now, on how to implement local interfaces in C++. > I'd be very wary of allowing several implementations: this > would make the mapping complicated, introduce the risk that > vendors would not support all of them ... and then no > portability of implementation. > > Looking at mapping (1) [generated class does not derive > from LocalObject], (2) [generated class derives from > LocalObject], and (3) [only a partial class gets generated > that the user fills in], my least favorite is (3): > - typically a class implementation has data members; I > doubt we could specify a portable way to add data members > to a partially generated class. > - the C++ mapping already deals with two similar issues > (how to implement POA servants, how to implement value > types) through entirely generated base classes that the > user derives from to provide implementations. > > Regarding (1) and (2), whether or not the sometimes costly > virtual inheritance is required is a reasonable criteria. > But I think it's actually the opposite to what you > presented: (1) does not require virtual inheritance > while (2) does. > > Say we have: > interface A {}; > interface B {}; > interface C : A, B {} > > With (2), if the derivation from CORBA::LocalObject is non > virtual, we would get: > class A : public CORBA::LocalObject { ... }; > class B : public CORBA::LocalObject { ... }; > class C : public virtual A, public virtual B { ... }; > > Unfortunately we get two LocalObjects in every C instance. > > Since the IDL compiler can't anticipate future derivation, > the only safe mapping is to generate virtual derivation > from LocalObject: > class A : public virtual CORBA::LocalObject { ... }; > etc. > > With (1), it's up to the user to use or not to use virtual > inheritance. AImpl and BImpl could be: > class AImpl: public A, public CORBA::LocalObject { ... }; > class BImpl: public B, public CORBA::LocalObject { ... }; > > With such AImpl and BImpl, it would not be possible to > write a CImpl that simply derives from both AImpl and BImpl > (we'd get two LocalObjects) ... but that's the user problem. > He can switch to virtual inheritance if we wants such > multiple inheritance reuse. > > Best regards, > > Bernard > > > -----Original Message----- > > From: Bill Beckwith [mailto:bill.beckwith@ois.com] > > Sent: Tuesday, December 03, 2002 10:26 PM > > To: Jishnu Mukerji > > Cc: cxx_revision@omg.org; andrew@omg.org > > Subject: Re: Proposal for C++ local interface mapping (issue #5579) > > > > > > At 04:22 PM 12/3/2002, Jishnu Mukerji wrote: > > > > > > > > >Bill Beckwith wrote: > > >> > > >> [As a point of order mapping local interfaces to C++ is > > >> a major change and requires an RFP.] > > > > > >Sorry Bill, I think you misunderstand the current state of affairs. > > > > I am well aware of the extent of the current mapping of local > > interfaces to C++. > > > > >Local Interfaces are already mapped to C++ as per the > > adopted Components > > >Specification, and the updated C++ mapping standard can be > found at: > > > > > > http://doc.omg.org/ptc/02-08-08 > > > > As you mention below, the current local interface mapping does > > not specify the semantics for implementations of local interfaces > > other than: > > > > A locality constrained object is implemented by a class derived > > both from the class mapping the interface and from > > CORBA::LocalObject. > > > > >All that the RTF is trying to do is fix the > > incompleteness/buggyness of > > >the adopted specification, which is what RTFs are supposed to do. > > > > What you are calling an "incomplete" specification is one that > > gave several embedded ORBs the freedom to provide very lightweight > > local interface mappings. Given the strong popularity of CORBA in > > embedded systems these days it would be a shame to unnecessarily > > bloat these embedded ORBs and user authors of local interfaces. > > > > Thus I don't consider the existing specification broken in this > > particular regard. > > > > >BTW, the adopted text related to C++ mapping of Loca > Objects clearly > > >states: > > > > > >"The C++ mapping of Local Object is a class derived from > > CORBA::Object > > >that is used as a base class for locality constrained object > > >implementations. A locality constrained object is > > implemented by a class > > >derived both from the class mapping the interface and from > > >CORBA::LocalObject." > > > > Yes, it does. And the LocalIF class in your examples below > > satisfies the requirements of a "derived both from the class mapping > > the interface and from CORBA::LocalObject" > > > > >So we have to agree upong whether the inheritnce tree looks like: > > > > > >1. Jon's proposal: > > > > > >// C++ > > > class LocalIF { ... } // IDL compiler generated > > > > > > class MyLocalIF : public LocalIF, public > CORBA::LocalObject { ... } > > > > Jon probably meant to make these virtual inheritance. > > > > >or 2. Other apparent proposal: > > > > > >// C++ > > > class LocalIF : CORBA::LocalObject {....} // IDL > compiler generated > > > > > > class MyLocalIF : public LocalIF { .... } > > > > Here no virtual inheritance is required (which is a > > very good thing). > > > > There is also a third option where LocalIF is generated in > such a way > > that a user can provide the operation implementations: > > > > IDL compiler: > > > > class LocalIF : public CORBA::LocalObject > > { > > virtual void op1(); > > } > > > > User writes: > > > > void LocalIF::op1() > > { > > // ... > > } > > > > Note that to the client of a local interface approaches > > (1), (2), and (3) all are code compatible. There are > > implementation differences for someone providing a local > > interface. But the specification doesn't fill provide > > those semantics. It is adding those semantics that I > > believe is a significant change. > > > > My preference (in order of decreasing preference): > > > > (A) constraint the spec to (3) > > (B) leave the spec so that it allows either (1), (2), or (3) > > (C) constraining the spec to (2) > > > > Unfortunately I fear that (A) and (C) may be out of scope > > for an RTF. > > > > >Unfortunately the language used in the adopted spec > appears to admit > > >both of the possibilities enumerated above. We should choose > > one after > > >weighing the pros and cons of that choice. > > > > Agreed. > > > > >We should also keep in mind that (I believe) that the > > original intent of > > >the submitters of the Component Specification's Local > > Interface portion > > >was always to allow local implementation of non-local > interfaces as a > > >means for moving all the locality constrained interfaces to local > > >interfaces relatively painlessly without unnecessarily > > breaking code. So > > >I don't think tha a general position stating that > "providing a local > > >implementation for a non-local interface (as in pseudo > IDL) should be > > >out of scope of the C++ mapping" is not sustainable based on > > the history > > >of development of this feature. > > > > I may be mincing words here with you but I'm not saying > that extending > > the semantics of local interface implementations is out of > > scope for the > > C++ mapping. I am saying that it is out of scope for the C++ RTF. > > This needs to be done in an RFP submission. > > > > >The bottom line is, it would be very appropriate to limit > > the activities > > >of the RTF to fixing the problems with the adopted > specification and > > >refraining from doing a ground up redesign of the same. > > > > I agree. Incremental fixes to existing semantics are appropriate. > > Wholesale changes or extensions of the spec are inappropriate. > > > > And since the ambiguities of the existing spec allowed the > > optimization > > of existing implementations we should be careful not to > plunder those > > optimizations. If a change does this, however minor the > > change appears, > > the change should definitely be considered a major > > specification change. > > > > Bill > > > > > > > Date: Tue, 10 Dec 2002 16:52:51 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: "Normier, Bernhard" Cc: cxx_revision@omg.org Subject: Re: Proposal for C++ local interface mapping (issue #5579) Bernard, I generally agree with your analysis. Jishnu. "Normier, Bernhard" wrote: > > This time around I'd like to get a resolution to this local > interface mapping issue, not let the discussion die. > > You can find my opinion in the e-mail below. If more people > could provide their opinion, maybe a consensus or at least > a majority could be found ... which would make a successful > resolution more likely. > > Thanks, > > Bernard > > > -----Original Message----- > > From: Normier, Bernhard > > Sent: Wednesday, December 04, 2002 2:52 PM > > To: Bill Beckwith; Jishnu Mukerji > > Cc: cxx_revision@omg.org; andrew@omg.org > > Subject: RE: Proposal for C++ local interface mapping (issue #5579) > > > > > > Hi Bill, > > > > As chair of this RTF, I am trying to get a number of open > > issues resolved. There are many open issues related to Local > > Interfaces, and a number of people consider their resolution > > rather urgent. > > A possible resolution for some issue can be that it's outside > > of the scope of an RTF ... but like Jishnu I fear this would > > mean several years before any resolution. > > > > Now, on how to implement local interfaces in C++. > > I'd be very wary of allowing several implementations: this > > would make the mapping complicated, introduce the risk that > > vendors would not support all of them ... and then no > > portability of implementation. > > > > Looking at mapping (1) [generated class does not derive > > from LocalObject], (2) [generated class derives from > > LocalObject], and (3) [only a partial class gets generated > > that the user fills in], my least favorite is (3): > > - typically a class implementation has data members; I > > doubt we could specify a portable way to add data members > > to a partially generated class. > > - the C++ mapping already deals with two similar issues > > (how to implement POA servants, how to implement value > > types) through entirely generated base classes that the > > user derives from to provide implementations. > > > > Regarding (1) and (2), whether or not the sometimes costly > > virtual inheritance is required is a reasonable criteria. > > But I think it's actually the opposite to what you > > presented: (1) does not require virtual inheritance > > while (2) does. > > > > Say we have: > > interface A {}; > > interface B {}; > > interface C : A, B {} > > > > With (2), if the derivation from CORBA::LocalObject is non > > virtual, we would get: > > class A : public CORBA::LocalObject { ... }; > > class B : public CORBA::LocalObject { ... }; > > class C : public virtual A, public virtual B { ... }; > > > > Unfortunately we get two LocalObjects in every C instance. > > > > Since the IDL compiler can't anticipate future derivation, > > the only safe mapping is to generate virtual derivation > > from LocalObject: > > class A : public virtual CORBA::LocalObject { ... }; > > etc. > > > > With (1), it's up to the user to use or not to use virtual > > inheritance. AImpl and BImpl could be: > > class AImpl: public A, public CORBA::LocalObject { ... }; > > class BImpl: public B, public CORBA::LocalObject { ... }; > > > > With such AImpl and BImpl, it would not be possible to > > write a CImpl that simply derives from both AImpl and BImpl > > (we'd get two LocalObjects) ... but that's the user problem. > > He can switch to virtual inheritance if we wants such > > multiple inheritance reuse. > > > > Best regards, > > > > Bernard > > > > > -----Original Message----- > > > From: Bill Beckwith [mailto:bill.beckwith@ois.com] > > > Sent: Tuesday, December 03, 2002 10:26 PM > > > To: Jishnu Mukerji > > > Cc: cxx_revision@omg.org; andrew@omg.org > > > Subject: Re: Proposal for C++ local interface mapping (issue #5579) > > > > > > > > > At 04:22 PM 12/3/2002, Jishnu Mukerji wrote: > > > > > > > > > > > >Bill Beckwith wrote: > > > >> > > > >> [As a point of order mapping local interfaces to C++ is > > > >> a major change and requires an RFP.] > > > > > > > >Sorry Bill, I think you misunderstand the current state of affairs. > > > > > > I am well aware of the extent of the current mapping of local > > > interfaces to C++. > > > > > > >Local Interfaces are already mapped to C++ as per the > > > adopted Components > > > >Specification, and the updated C++ mapping standard can be > > found at: > > > > > > > > http://doc.omg.org/ptc/02-08-08 > > > > > > As you mention below, the current local interface mapping does > > > not specify the semantics for implementations of local interfaces > > > other than: > > > > > > A locality constrained object is implemented by a class derived > > > both from the class mapping the interface and from > > > CORBA::LocalObject. > > > > > > >All that the RTF is trying to do is fix the > > > incompleteness/buggyness of > > > >the adopted specification, which is what RTFs are supposed to do. > > > > > > What you are calling an "incomplete" specification is one that > > > gave several embedded ORBs the freedom to provide very lightweight > > > local interface mappings. Given the strong popularity of CORBA in > > > embedded systems these days it would be a shame to unnecessarily > > > bloat these embedded ORBs and user authors of local interfaces. > > > > > > Thus I don't consider the existing specification broken in this > > > particular regard. > > > > > > >BTW, the adopted text related to C++ mapping of Loca > > Objects clearly > > > >states: > > > > > > > >"The C++ mapping of Local Object is a class derived from > > > CORBA::Object > > > >that is used as a base class for locality constrained object > > > >implementations. A locality constrained object is > > > implemented by a class > > > >derived both from the class mapping the interface and from > > > >CORBA::LocalObject." > > > > > > Yes, it does. And the LocalIF class in your examples below > > > satisfies the requirements of a "derived both from the class mapping > > > the interface and from CORBA::LocalObject" > > > > > > >So we have to agree upong whether the inheritnce tree looks like: > > > > > > > >1. Jon's proposal: > > > > > > > >// C++ > > > > class LocalIF { ... } // IDL compiler generated > > > > > > > > class MyLocalIF : public LocalIF, public > > CORBA::LocalObject { ... } > > > > > > Jon probably meant to make these virtual inheritance. > > > > > > >or 2. Other apparent proposal: > > > > > > > >// C++ > > > > class LocalIF : CORBA::LocalObject {....} // IDL > > compiler generated > > > > > > > > class MyLocalIF : public LocalIF { .... } > > > > > > Here no virtual inheritance is required (which is a > > > very good thing). > > > > > > There is also a third option where LocalIF is generated in > > such a way > > > that a user can provide the operation implementations: > > > > > > IDL compiler: > > > > > > class LocalIF : public CORBA::LocalObject > > > { > > > virtual void op1(); > > > } > > > > > > User writes: > > > > > > void LocalIF::op1() > > > { > > > // ... > > > } > > > > > > Note that to the client of a local interface approaches > > > (1), (2), and (3) all are code compatible. There are > > > implementation differences for someone providing a local > > > interface. But the specification doesn't fill provide > > > those semantics. It is adding those semantics that I > > > believe is a significant change. > > > > > > My preference (in order of decreasing preference): > > > > > > (A) constraint the spec to (3) > > > (B) leave the spec so that it allows either (1), (2), or (3) > > > (C) constraining the spec to (2) > > > > > > Unfortunately I fear that (A) and (C) may be out of scope > > > for an RTF. > > > > > > >Unfortunately the language used in the adopted spec > > appears to admit > > > >both of the possibilities enumerated above. We should choose > > > one after > > > >weighing the pros and cons of that choice. > > > > > > Agreed. > > > > > > >We should also keep in mind that (I believe) that the > > > original intent of > > > >the submitters of the Component Specification's Local > > > Interface portion > > > >was always to allow local implementation of non-local > > interfaces as a > > > >means for moving all the locality constrained interfaces to local > > > >interfaces relatively painlessly without unnecessarily > > > breaking code. So > > > >I don't think tha a general position stating that > > "providing a local > > > >implementation for a non-local interface (as in pseudo > > IDL) should be > > > >out of scope of the C++ mapping" is not sustainable based on > > > the history > > > >of development of this feature. > > > > > > I may be mincing words here with you but I'm not saying > > that extending > > > the semantics of local interface implementations is out of > > > scope for the > > > C++ mapping. I am saying that it is out of scope for the C++ RTF. > > > This needs to be done in an RFP submission. > > > > > > >The bottom line is, it would be very appropriate to limit > > > the activities > > > >of the RTF to fixing the problems with the adopted > > specification and > > > >refraining from doing a ground up redesign of the same. > > > > > > I agree. Incremental fixes to existing semantics are appropriate. > > > Wholesale changes or extensions of the spec are inappropriate. > > > > > > And since the ambiguities of the existing spec allowed the > > > optimization > > > of existing implementations we should be careful not to > > plunder those > > > optimizations. If a change does this, however minor the > > > change appears, > > > the change should definitely be considered a major > > > specification change. > > > > > > Bill > > > > > > > > > > > -- Jishnu Mukerji Senior Systems Architect 1001 Frontier Road, Suite 300 Technology Office Bridgewater NJ 08807, USA Software Global Business Unit Tel: +1 908 243 8924 Hewlett-Packard Company Fax: +1 908 243 8850 mailto: jishnu@hp.com Sender: jon@floorboard.com Date: Tue, 10 Dec 2002 17:07:21 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: "Normier, Bernhard" CC: cxx_revision@omg.org Subject: Re: Proposal for C++ local interface mapping (issue #5579) "Normier, Bernhard" wrote: > > The C++ local interface mapping still needs to be addressed; > a resolution could/should address a number of open issues > (4160, 4172, 4186, 4245, 4496, 4545, 5579, 5580). > > Unfortunately there was no consensus on Jon's proposal a few > months ago, and I don't see how an agreement or consensus on > the _add_ref/_remove_ref could be reached. > > To resolve this matter, I suggest to vote on two proposals: > - the mapping of local interface with _add_ref and _remove_ref > (thread-safe by default) > - the removal of _add_ref and _remove_ref from CORBA::LocalObject > (which I strongly oppose). > > You will find draft proposals below; I intend to submit them to > a vote (after discussion and amendment if necessary) in the next > few days. Ok, rather than responding to individual posts, I'll summarize and weigh in with my thoughts in one response, and add a few specific comments about other posts. First an analysis of the issue: The current specification for LocalObject in C++ is inadequate. It does not explicitly explain in exact detail how to implement a local object, and since the adoption of PI, it is necessary for a normal mortal application programmer to do this. The specific area that is underspecified is whether the IDL compiler or the user must do the derivation from CORBA::LocalObject. The issue of reference count management is also underspecified. In particular, it is impossible with the current specification to write a portable implementation of _add_ref() and _remove_ref(), since the C++ mapping does not provide system-independent mechanisms to protect data from access by multiple threads. Also, there is a question of the usefulness of allowing a programmer to provide custom implementations of the reference count mechanism, presumably for performance reasons, and to permit the possibility of allocating a local object implementation class on the C++ stack. Here are my opinions on these issues: First, having the IDL compiler generate local objects derived from CORBA::LocalObject causes problems with multiple inheritence, since it would require CORBA::LocalObject to be a virtual base class. I think most people would prefer a solution that avoids that overhead. So the implementor of the local object must manually derive it from CORBA::LocalObject, and can still do so virtually if she wants to share implementation details among mulpile local object implementations. Second, we must have an available implementation of the reference counting that is thread safe and portable. I think it is error prone to make it the "default" implementation that can be overridden by the user, and it still leaves the overhead in the local object for storage of the needed mutex. That leaves two options: make the thread-safe reference counting implementation mandatory and part of the definition of LocalObject (thus removing the ability to override _add_ref() et al), or else provide an extra mixin class that provides the safe implementation. I'm not really convinced that the need for "custom" reference counting implementations has been adequately demonstrated, since the thread-safe version can be implemented in a way that is just as safe to allocate on the stack as a non-referenced counted version, but I won't shoot it down if it is clear that my opinion is in the minority. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@floorboard.com Date: Tue, 10 Dec 2002 17:08:38 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: "Pilhofer, Frank" CC: "'Normier, Bernhard'" , cxx_revision@omg.org Subject: Re: Proposal for C++ local interface mapping (issue #5579) "Pilhofer, Frank" wrote: > As for Jon's last comment, there is an IDL:omg.org/CORBA/LocalBase:1.0 > Repository Id (page 10-42 in CORBA 3 in the LocalInterfaceDef section), > so _is_a on a Local Object using this Id must return true (or that > paragraph needs to be changed). That is only for calling is_a() on an InterfaceDef from the IR. There is no specific requirement that it also work when calling _is_a() on a random object reference. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 11 Dec 2002 18:00:49 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: "Pilhofer, Frank" , "'Normier, Bernhard'" , cxx_revision@omg.org Subject: Re: Proposal for C++ local interface mapping (issue #5579) Jonathan Biggar wrote: > > "Pilhofer, Frank" wrote: > > As for Jon's last comment, there is an IDL:omg.org/CORBA/LocalBase:1.0 > > Repository Id (page 10-42 in CORBA 3 in the LocalInterfaceDef section), > > so _is_a on a Local Object using this Id must return true (or that > > paragraph needs to be changed). > > That is only for calling is_a() on an InterfaceDef from the IR. There > is no specific requirement that it also work when calling _is_a() on a > random object reference. Yep, for local objects: is_a - returns TRUE if the LocalObject derives from or is itself the type specified by the logical_type_id argument. Unlike for the description of is_a as applied to general object references, where the behavior for repId "IDL:omg.org/CORBA/Object:1.0" is mentioned explicitly in section 4.3.4.1, there is no such specification of special behavior for is_a for LocalObjects in section 4.3.13. Jishnu. Sender: jon@floorboard.com Date: Wed, 11 Dec 2002 15:10:17 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.8 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en To: Jishnu Mukerji CC: "Pilhofer, Frank" , "'Normier, Bernhard'" , cxx_revision@omg.org Subject: Re: Proposal for C++ local interface mapping (issue #5579) Jishnu Mukerji wrote: > > > As for Jon's last comment, there is an IDL:omg.org/CORBA/LocalBase:1.0 > > > Repository Id (page 10-42 in CORBA 3 in the LocalInterfaceDef section), > > > so _is_a on a Local Object using this Id must return true (or that > > > paragraph needs to be changed). > > > > That is only for calling is_a() on an InterfaceDef from the IR. There > > is no specific requirement that it also work when calling _is_a() on a > > random object reference. > > Yep, for local objects: > > * is_a - returns TRUE if the LocalObject derives from or is itself the > type > specified by the logical_type_id argument. > > Unlike for the description of is_a as applied to general object > references, where the behavior for repId "IDL:omg.org/CORBA/Object:1.0" > is mentioned explicitly in section 4.3.4.1, there is no such > specification of special behavior for is_a for LocalObjects in section > 4.3.13. I'm not sure if you agreed with me or with Frank. Could you clarify? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Thu, 12 Dec 2002 11:27:14 -0500 From: Jishnu Mukerji Organization: Software Global Business Unit, Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: Jonathan Biggar Cc: "Pilhofer, Frank" , "'Normier, Bernhard'" , cxx_revision@omg.org Subject: Re: Proposal for C++ local interface mapping (issue #5579) Jonathan Biggar wrote: > > Jishnu Mukerji wrote: > > > > As for Jon's last comment, there is an IDL:omg.org/CORBA/LocalBase:1.0 > > > > Repository Id (page 10-42 in CORBA 3 in the LocalInterfaceDef section), > > > > so _is_a on a Local Object using this Id must return true (or that > > > > paragraph needs to be changed). > > > > > > That is only for calling is_a() on an InterfaceDef from the IR. There > > > is no specific requirement that it also work when calling _is_a() on a > > > random object reference. > > > > Yep, for local objects: > > > > * is_a - returns TRUE if the LocalObject derives from or is itself the > > type > > specified by the logical_type_id argument. > > > > Unlike for the description of is_a as applied to general object > > references, where the behavior for repId "IDL:omg.org/CORBA/Object:1.0" > > is mentioned explicitly in section 4.3.4.1, there is no such > > specification of special behavior for is_a for LocalObjects in section > > 4.3.13. > > I'm not sure if you agreed with me or with Frank. Could you clarify? Jon, I agree with you. Jishnu.