Issue 3456: Policy overrides on RTPortableServer::POA (rt-corba-ftf) Source: Objective Interface Systems (Mr. Bill Beckwith, r.william.beckwith(at)ois.com) Nature: Uncategorized Issue Severity: Summary: It is implicit that you can override policies on RTPortableServer::POA since it inherits from CORBA::Object. This should be explicitly stated. Resolution: close issue Revised Text: Resolution: Close this issue withougt change. There is no reason to use the CORBA::Object::set_policy_overrides operation on RTPortableServer::POA. Real-Time CORBA policies, like all other policies, may be set at POA creation, and may not be changed after that. Disposition : Rejected Actions taken: March 23, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== X-Sender: beckwb@192.84.85.3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 23 Mar 2000 18:02:01 -0500 To: rt-corba-ftf@omg.org From: Bill Beckwith Subject: Policy overrides on RTPortableServer::POA Cc: issues@omg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: ?f^!!9_#e9*6l!!a>l!! It is implicit that you can override policies on RTPortableServer::POA since it inherits from CORBA::Object. This should be explicitly stated. -- Bill Sender: jon Message-ID: <390E01E1.CFD46FB8@highlander.com> Date: Mon, 01 May 2000 18:14:57 -0400 From: Jon Currey Organization: Highlander X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rt-corba-ftf@omg.org CC: Jishnu Mukerji Subject: Re: Issues 3454, 3455 and 3456 : Policy overrides Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: RV-e9-c+e9>M+e9@G\d9 Bill Are you sure about these three related issues? If so, can you propse specific new text for each of them? (See below for issue summaries.) I'm not clear on the issues, for the following reasons : Yes, RTCORBA::Current, RTCORBA::RTORB and RTPortableServer::POA do all implicitly inherit from CORBA::Object (because they are defined in IDL). But section 4.3.8.1 of CORBA 2.3.1 (page 4-14) states the following about CORBA::Object::set_policy_overrides : "Only certain policies that pertain to the invocation of an operation at the client end can be overridden using this operation. Attempts to override any other policy will result in the raising of the CORBA::NO_PERMISSION exception." These objects are locality constrained. Isn't CORBA::Object::set_policy_overrides only meant for use with use with 'regular' (non0`-locality constrained, non-ORB object) Object References? Another way of getting at the problem : Can CORBA::Object::set_policy_overrides be used to change policies on instances of PortableServer::POA, CORBA::ORB etc? I think not. For one thing, aren't POA policies immutable? Also, remember that CORBA::Object::set_policy_overrides returns another instance of the object reference. The original (instance of the) object reference is still valid though, so you now effectively have two handles to the same instance, each with different policy values. This doesn't seem to match up with the behaviour of POA, ORB and Current. It shouldn't matter which reference to a given POA you have. The policies are a property of the POA, not the reference. What do you think? Can anyone else see what I'm getting at, and perhaps articulate it better? Jon. ------------------------------------------------------------------------------------------------ Issue 3454: Policy overrides on RTCORBA::Current (rt-corba-ftf) Summary: It is implicit that you can override policies on RTCORBA::Current since it inherits from CORBA::Object. This should be explicitly stated. Issue 3455: Policy overrides on RTCORBA::RTORB (rt-corba-ftf) Summary: It is implicit that you can override policies on RTCORBA::RTORB since it inherits from CORBA::Object. This should be explicitly stated. Issue 3456: Policy overrides on RTPortableServer::POA (rt-corba-ftf) Summary: It is implicit that you can override policies on RTPortableServer::POA since it inherits from CORBA::Object. This should be explicitly stated. Sender: jon Message-ID: <390E31A9.D791698A@highlander.com> Date: Mon, 01 May 2000 21:38:49 -0400 From: Jon Currey Organization: Highlander X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rt-corba-ftf@omg.org, Bill Beckwith CC: Jishnu Mukerji Subject: Re: Issues 3454, 3455 and 3456 : Policy overrides References: <390E01E1.CFD46FB8@highlander.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: dp'!!80J!!W7#!!nMd!! Further thoughts on this one ... Bill, is the motivation for raising these issues wanting to explicitly identify the parts of the CORBA QoS policy framework that are to be used to override RT CORBA policies at the different scopes? (i.e. at ORB scope, Current scope and Obj Ref scope.) I think that that is a good thing to do. Some of the other issues, such as Dave's, are also about explaining how policies are applied and overridden at different scopes. The problem could be that CORBA 2.3 doesn't include all of the QoS policy framework. The way to override policies at ORB scope isn't through CORBA::Object::set_policy_overrides, but through the ORB scoped PolicyManager, as defined in section 4.9.3 of CORBA 2.4 (looking at the draft ptc/00-03-02.) And policies at Current scope are overridden using PolicyCurrent, defined in the same section. POA policies cannot be overridden after POA creation. So, I can envision a proposal for issue 3454 based on referencing the use of PolicyCurrent, a proposal for issue 3455 based on referencing the use of the ORB PolicyManager, and closing issue 3456 without action. Is this what you had in mind? If so, we can work out the wording in a short time tomorrow. (I'm assume we are going to move to being based off of CORBA 2.4, which is the case, I believe from an earlier discussion of issue 2905.) Jon. Jon Currey wrote: > > Bill > > Are you sure about these three related issues? If so, can you propse specific > new text for each of them? (See below for issue summaries.) > > I'm not clear on the issues, for the following reasons : > > Yes, RTCORBA::Current, RTCORBA::RTORB and RTPortableServer::POA do all implicitly > inherit from CORBA::Object (because they are defined in IDL). > > But section 4.3.8.1 of CORBA 2.3.1 (page 4-14) states the following about > CORBA::Object::set_policy_overrides : > "Only certain policies that pertain to the invocation of an operation at the client > end can be overridden using this operation. Attempts to override any other policy > will result in the raising of the CORBA::NO_PERMISSION exception." > > These objects are locality constrained. Isn't CORBA::Object::set_policy_overrides > only meant for use with use with 'regular' (non0`-locality constrained, non-ORB object) > Object References? > > Another way of getting at the problem : Can CORBA::Object::set_policy_overrides be > used to change policies on instances of PortableServer::POA, CORBA::ORB etc? > I think not. For one thing, aren't POA policies immutable? Also, remember that > CORBA::Object::set_policy_overrides returns another instance of the object reference. > The original (instance of the) object reference is still valid though, so you now > effectively have two handles to the same instance, each with different policy values. > This doesn't seem to match up with the behaviour of POA, ORB and Current. It shouldn't > matter which reference to a given POA you have. The policies are a property of the > POA, not the reference. > > What do you think? Can anyone else see what I'm getting at, and perhaps articulate it > better? > > Jon. > > ------------------------------------------------------------------------------------------------ > > Issue 3454: Policy overrides on RTCORBA::Current (rt-corba-ftf) > > Summary: It is implicit that you can override policies on RTCORBA::Current since it inherits > from CORBA::Object. This should be explicitly stated. > > Issue 3455: Policy overrides on RTCORBA::RTORB (rt-corba-ftf) > > Summary: It is implicit that you can override policies on RTCORBA::RTORB since it inherits from > CORBA::Object. This should be explicitly stated. > > Issue 3456: Policy overrides on RTPortableServer::POA (rt-corba-ftf) > > Summary: It is implicit that you can override policies on RTPortableServer::POA since it > inherits from CORBA::Object. This should be explicitly stated. Sender: jon Message-ID: <39104F6E.3C6FF590@highlander.com> Date: Wed, 03 May 2000 12:10:22 -0400 From: Jon Currey Organization: Highlander X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Beckwith CC: rt-corba-ftf@omg.org Subject: Re: Issues 3454, 3455 and 3456 : Policy overrides References: <390E01E1.CFD46FB8@highlander.com> <390E31A9.D791698A@highlander.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: neBe9]<=e9]7R!!E8>!! Bill, did you have a chance to consider these three issues further? We don't currently have a proposal for any of them. As stated in my previous e-mails (below), I believe that the issues are ill-formed, and suspect that the issues you wanted to address are different to the issues as raised. I'd be happy for us to vote on a proposal that addresses the true issue (provided I was right in thinking that that is the true issue), but we need proposal text to vote on in the next few hours, as I intend to kick off the voting at 5pm EST today. Without proposal text, I will propose that we vote to close these three issues without change. Jon. Jon Currey wrote: > > Further thoughts on this one ... > > Bill, is the motivation for raising these issues wanting to explicitly identify the > parts of the CORBA QoS policy framework that are to be used to override RT CORBA > policies at the different scopes? (i.e. at ORB scope, Current scope and Obj Ref scope.) > > I think that that is a good thing to do. Some of the other issues, such as Dave's, are > also about explaining how policies are applied and overridden at different scopes. > > The problem could be that CORBA 2.3 doesn't include all of the QoS policy framework. > The way to override policies at ORB scope isn't through CORBA::Object::set_policy_overrides, > but through the ORB scoped PolicyManager, as defined in section 4.9.3 of CORBA 2.4 > (looking at the draft ptc/00-03-02.) And policies at Current scope are overridden using > PolicyCurrent, defined in the same section. POA policies cannot be overridden after > POA creation. > > So, I can envision a proposal for issue 3454 based on referencing the use of PolicyCurrent, > a proposal for issue 3455 based on referencing the use of the ORB PolicyManager, and > closing issue 3456 without action. > > Is this what you had in mind? If so, we can work out the wording in a short time tomorrow. > > (I'm assume we are going to move to being based off of CORBA 2.4, which is the case, I > believe from an earlier discussion of issue 2905.) > > Jon. > > Jon Currey wrote: > > > > Bill > > > > Are you sure about these three related issues? If so, can you propse specific > > new text for each of them? (See below for issue summaries.) > > > > I'm not clear on the issues, for the following reasons : > > > > Yes, RTCORBA::Current, RTCORBA::RTORB and RTPortableServer::POA do all implicitly > > inherit from CORBA::Object (because they are defined in IDL). > > > > But section 4.3.8.1 of CORBA 2.3.1 (page 4-14) states the following about > > CORBA::Object::set_policy_overrides : > > "Only certain policies that pertain to the invocation of an operation at the client > > end can be overridden using this operation. Attempts to override any other policy > > will result in the raising of the CORBA::NO_PERMISSION exception." > > > > These objects are locality constrained. Isn't CORBA::Object::set_policy_overrides > > only meant for use with use with 'regular' (non0`-locality constrained, non-ORB object) > > Object References? > > > > Another way of getting at the problem : Can CORBA::Object::set_policy_overrides be > > used to change policies on instances of PortableServer::POA, CORBA::ORB etc? > > I think not. For one thing, aren't POA policies immutable? Also, remember that > > CORBA::Object::set_policy_overrides returns another instance of the object reference. > > The original (instance of the) object reference is still valid though, so you now > > effectively have two handles to the same instance, each with different policy values. > > This doesn't seem to match up with the behaviour of POA, ORB and Current. It shouldn't > > matter which reference to a given POA you have. The policies are a property of the > > POA, not the reference. > > > > What do you think? Can anyone else see what I'm getting at, and perhaps articulate it > > better? > > > > Jon. > > > > ------------------------------------------------------------------------------------------------ > > > > Issue 3454: Policy overrides on RTCORBA::Current (rt-corba-ftf) > > > > Summary: It is implicit that you can override policies on RTCORBA::Current since it inherits > > from CORBA::Object. This should be explicitly stated. > > > > Issue 3455: Policy overrides on RTCORBA::RTORB (rt-corba-ftf) > > > > Summary: It is implicit that you can override policies on RTCORBA::RTORB since it inherits from > > CORBA::Object. This should be explicitly stated. > > > > Issue 3456: Policy overrides on RTPortableServer::POA (rt-corba-ftf) > > > > Summary: It is implicit that you can override policies on RTPortableServer::POA since it > > inherits from CORBA::Object. This should be explicitly stated. X-Sender: beckwb@192.84.85.3 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 03 May 2000 19:48:15 -0400 To: Jon Currey From: Bill Beckwith Subject: Re: Issues 3454, 3455 and 3456 : Policy overrides Cc: rt-corba-ftf@omg.org In-Reply-To: <39104F6E.3C6FF590@highlander.com> References: <390E01E1.CFD46FB8@highlander.com> <390E31A9.D791698A@highlander.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: :ZNd9e/Ee9M>Qe9>F4e9 At 12:10 PM 5/3/00, Jon Currey wrote: > >Bill, did you have a chance to consider these three issues >further? We don't currently have a proposal for any of them. I did work up some text but I haven't completed them. >As stated in my previous e-mails (below), I believe that the >issues are ill-formed, and suspect that the issues you wanted to >address are different to the issues as raised. I'd be happy for >us to vote on a proposal that addresses the true issue (provided >I was right in thinking that that is the true issue), but we >need proposal text to vote on in the next few hours, as I intend >to kick off the voting at 5pm EST today. I appreciate the points you have made on this. I think the problem has come about because we have parallel abstractions to the PIDL object that one would normally apply policies to. >Without proposal text, I will propose that we vote to close >these three issues without change. Unresolved issues shouldn't be closed. They should be left open. -- Bill >Jon Currey wrote: >> >> Further thoughts on this one ... >> >> Bill, is the motivation for raising these issues wanting to >> explicitly identify the parts of the CORBA QoS policy >> framework that are to be used to override RT CORBA policies at >> the different scopes? (i.e. at ORB scope, Current scope and >> Obj Ref scope.) >> >> I think that that is a good thing to do. Some of the other >> issues, such as Dave's, are also about explaining how policies >> are applied and overridden at different scopes. >> >> The problem could be that CORBA 2.3 doesn't include all of the >> QoS policy framework. The way to override policies at ORB >> scope isn't through CORBA::Object::set_policy_overrides, but >> through the ORB scoped PolicyManager, as defined in section >> 4.9.3 of CORBA 2.4 (looking at the draft ptc/00-03-02.) And >> policies at Current scope are overridden using PolicyCurrent, >> defined in the same section. POA policies cannot be overridden >> after POA creation. >> >> So, I can envision a proposal for issue 3454 based on >> referencing the use of PolicyCurrent, a proposal for issue >> 3455 based on referencing the use of the ORB PolicyManager, >> and closing issue 3456 without action. >> >> Is this what you had in mind? If so, we can work out the >> wording in a short time tomorrow. >> >> (I'm assume we are going to move to being based off of CORBA >> 2.4, which is the case, I believe from an earlier discussion >> of issue 2905.) >> >> Jon. >> Jon Currey wrote: >> > >> > Bill >> > >> > Are you sure about these three related issues? If so, can >> > you propse specific new text for each of them? (See below >> > for issue summaries.) >> > >> > I'm not clear on the issues, for the following reasons : >> > >> > Yes, RTCORBA::Current, RTCORBA::RTORB and >> > RTPortableServer::POA do all implicitly inherit from >> > CORBA::Object (because they are defined in IDL). >> > >> > But section 4.3.8.1 of CORBA 2.3.1 (page 4-14) states the >> > following about CORBA::Object::set_policy_overrides : "Only >> > certain policies that pertain to the invocation of an >> > operation at the client end can be overridden using this >> > operation. Attempts to override any other policy will result >> > in the raising of the CORBA::NO_PERMISSION exception." >> > >> > These objects are locality constrained. Isn't >> > CORBA::Object::set_policy_overrides only meant for use with >> > use with 'regular' (non0`-locality constrained, non-ORB >> > object) Object References? >> > >> > Another way of getting at the problem : Can >> > CORBA::Object::set_policy_overrides be used to change >> > policies on instances of PortableServer::POA, CORBA::ORB >> > etc? I think not. For one thing, aren't POA policies >> > immutable? Also, remember that >> > CORBA::Object::set_policy_overrides returns another instance >> > of the object reference. The original (instance of the) >> > object reference is still valid though, so you now >> > effectively have two handles to the same instance, each with >> > different policy values. This doesn't seem to match up with >> > the behaviour of POA, ORB and Current. It shouldn't matter >> > which reference to a given POA you have. The policies are a >> > property of the POA, not the reference. >> > >> > What do you think? Can anyone else see what I'm getting at, >> > and perhaps articulate it better? >> > >> > Jon. >> > >> > >---------------------------------------------------------------------------- >> > >> > Issue 3454: Policy overrides on RTCORBA::Current >> > (rt-corba-ftf) >> > >> > Summary: It is implicit that you can override policies on >> > RTCORBA::Current since it inherits from CORBA::Object. This >> > should be explicitly stated. >> > >> > Issue 3455: Policy overrides on RTCORBA::RTORB >> > (rt-corba-ftf) >> > >> > Summary: It is implicit that you can override policies on >> > RTCORBA::RTORB since it inherits from CORBA::Object. This >> > should be explicitly stated. >> > >> > Issue 3456: Policy overrides on RTPortableServer::POA >> > (rt-corba-ftf) >> > >> > Summary: It is implicit that you can override policies on >> > RTPortableServer::POA since it inherits from CORBA::Object. >> > This should be explicitly stated. Date: Thu, 04 May 2000 14:33:00 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bill Beckwith Cc: Jon Currey , rt-corba-ftf@omg.org Subject: Re: Issues 3454, 3455 and 3456 : Policy overrides References: <390E01E1.CFD46FB8@highlander.com> <390E31A9.D791698A@highlander.com> <4.3.1.2.20000503194054.00bb8ab0@192.84.85.3> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: + > At 12:10 PM 5/3/00, Jon Currey wrote: > > > >Bill, did you have a chance to consider these three issues > >further? We don't currently have a proposal for any of them. > > I did work up some text but I haven't completed them. > > >As stated in my previous e-mails (below), I believe that the > >issues are ill-formed, and suspect that the issues you wanted to > >address are different to the issues as raised. I'd be happy for > >us to vote on a proposal that addresses the true issue (provided > >I was right in thinking that that is the true issue), but we > >need proposal text to vote on in the next few hours, as I intend > >to kick off the voting at 5pm EST today. > > I appreciate the points you have made on this. I think the > problem has come about because we have parallel abstractions to > the PIDL object that one would normally apply policies to. > > >Without proposal text, I will propose that we vote to close > >these three issues without change. > > Unresolved issues shouldn't be closed. They should be left open. Yep, no need to close issues just because there is no proposal. Some issues are inherently hard to address. That should not be a reason to lose them altogether. Jishnu. Sender: jon Message-ID: <3911FFB7.CB2178C6@highlander.com> Date: Thu, 04 May 2000 18:54:47 -0400 From: Jon Currey Organization: Highlander X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jis@fpk.hp.com CC: Bill Beckwith , rt-corba-ftf@omg.org Subject: Re: Issues 3454, 3455 and 3456 : Policy overrides References: <390E01E1.CFD46FB8@highlander.com> <390E31A9.D791698A@highlander.com> <4.3.1.2.20000503194054.00bb8ab0@192.84.85.3> <3911C25C.834A7485@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Y"Ld9-^3e9@?6!!-Ugd9 Jishnu Mukerji wrote: > > Bill Beckwith wrote: > > > > At 12:10 PM 5/3/00, Jon Currey wrote: > > > > > >Bill, did you have a chance to consider these three issues > > >further? We don't currently have a proposal for any of them. > > > > I did work up some text but I haven't completed them. > > > > >As stated in my previous e-mails (below), I believe that the > > >issues are ill-formed, and suspect that the issues you wanted to > > >address are different to the issues as raised. I'd be happy for > > >us to vote on a proposal that addresses the true issue (provided > > >I was right in thinking that that is the true issue), but we > > >need proposal text to vote on in the next few hours, as I intend > > >to kick off the voting at 5pm EST today. > > > > I appreciate the points you have made on this. I think the > > problem has come about because we have parallel abstractions to > > the PIDL object that one would normally apply policies to. > > > > >Without proposal text, I will propose that we vote to close > > >these three issues without change. > > > > Unresolved issues shouldn't be closed. They should be left open. > > Yep, no need to close issues just because there is no proposal. Some > issues are inherently hard to address. That should not be a reason to > lose them altogether. > > Jishnu. Jishnu I agree that there is no reason to close an issue just because there is no proposal. In this case, I am actually making a proposal, to close these issues without making changes to the spec. This is because I believe that these are non-issues (i.e. there is no need to do anything in this area.) I explained the reasoning behind this in the series of mails included below. To summarize the points : Yes, it is implicit that one can override policies on RTCORBA::Current, RTCORBA::RTORB and RTPortableServer::POA because they are defined in IDL, and hence inherit from CORBA::Object. However, this is not an interesting fact. Why would one want to override policies on these objects? Not in order to apply Real-Time CORBA Policies at the scope of ORB, Current and POA. There are different mechanisms for doing this, as described in the QoS Policy Framework defined in Messaging and included in part in CORBA 2.3 and in full in the CORBA 2.4 draft. Furthermore, I suspect that there may be an issue here for the core RTF. Why should it be permissible to perform a set_policy_overrides operation on a POA object. A POA's policies are immutable. Hence, I'm making a technical case for closing these issues without change. If people disagree, they can vote against my proposal, and the issues will not be closed. Jon. (Note that at one point I did say that I would be happy to vote on proposals that addressed what I suspected was the issue that had been meant to be raised : making explicit in the document how one sets and overrides Real-Time CORBA Policies at ORB and Current scope. But without confirmation that this was the intended issue, I decided to make a proposal that addressed the issues as stated, rather than assuming my surmise was correct. The 'correct' issues could always be raised in the first RTF - especially as these are all just issues of textual clarification, and do not require a change to interface or semantics.) Jon Currey wrote: > > Bill, did you have a chance to consider these three issues further? We don't currently > have a proposal for any of them. > > As stated in my previous e-mails (below), I believe that the issues are ill-formed, and > suspect that the issues you wanted to address are different to the issues as raised. I'd be > happy for us to vote on a proposal that addresses the true issue (provided I was right in > thinking that that is the true issue), but we need proposal text to vote on in the next > few hours, as I intend to kick off the voting at 5pm EST today. > > Without proposal text, I will propose that we vote to close these three issues without > change. > > Jon. > > Jon Currey wrote: > > > > Further thoughts on this one ... > > > > Bill, is the motivation for raising these issues wanting to explicitly identify the > > parts of the CORBA QoS policy framework that are to be used to override RT CORBA > > policies at the different scopes? (i.e. at ORB scope, Current scope and Obj Ref scope.) > > > > I think that that is a good thing to do. Some of the other issues, such as Dave's, are > > also about explaining how policies are applied and overridden at different scopes. > > > > The problem could be that CORBA 2.3 doesn't include all of the QoS policy framework. > > The way to override policies at ORB scope isn't through CORBA::Object::set_policy_overrides, > > but through the ORB scoped PolicyManager, as defined in section 4.9.3 of CORBA 2.4 > > (looking at the draft ptc/00-03-02.) And policies at Current scope are overridden using > > PolicyCurrent, defined in the same section. POA policies cannot be overridden after > > POA creation. > > > > So, I can envision a proposal for issue 3454 based on referencing the use of PolicyCurrent, > > a proposal for issue 3455 based on referencing the use of the ORB PolicyManager, and > > closing issue 3456 without action. > > > > Is this what you had in mind? If so, we can work out the wording in a short time tomorrow. > > > > (I'm assume we are going to move to being based off of CORBA 2.4, which is the case, I > > believe from an earlier discussion of issue 2905.) > > > > Jon. > > > > Jon Currey wrote: > > > > > > Bill > > > > > > Are you sure about these three related issues? If so, can you propse specific > > > new text for each of them? (See below for issue summaries.) > > > > > > I'm not clear on the issues, for the following reasons : > > > > > > Yes, RTCORBA::Current, RTCORBA::RTORB and RTPortableServer::POA do all implicitly > > > inherit from CORBA::Object (because they are defined in IDL). > > > > > > But section 4.3.8.1 of CORBA 2.3.1 (page 4-14) states the following about > > > CORBA::Object::set_policy_overrides : > > > "Only certain policies that pertain to the invocation of an operation at the client > > > end can be overridden using this operation. Attempts to override any other policy > > > will result in the raising of the CORBA::NO_PERMISSION exception." > > > > > > These objects are locality constrained. Isn't CORBA::Object::set_policy_overrides > > > only meant for use with use with 'regular' (non0`-locality constrained, non-ORB object) > > > Object References? > > > > > > Another way of getting at the problem : Can CORBA::Object::set_policy_overrides be > > > used to change policies on instances of PortableServer::POA, CORBA::ORB etc? > > > I think not. For one thing, aren't POA policies immutable? Also, remember that > > > CORBA::Object::set_policy_overrides returns another instance of the object reference. > > > The original (instance of the) object reference is still valid though, so you now > > > effectively have two handles to the same instance, each with different policy values. > > > This doesn't seem to match up with the behaviour of POA, ORB and Current. It shouldn't > > > matter which reference to a given POA you have. The policies are a property of the > > > POA, not the reference. > > > > > > What do you think? Can anyone else see what I'm getting at, and perhaps articulate it > > > better? > > > > > > Jon. > > > > > > ------------------------------------------------------------------------------------------------ > > > > > > Issue 3454: Policy overrides on RTCORBA::Current (rt-corba-ftf) > > > > > > Summary: It is implicit that you can override policies on RTCORBA::Current since it inherits > > > from CORBA::Object. This should be explicitly stated. > > > > > > Issue 3455: Policy overrides on RTCORBA::RTORB (rt-corba-ftf) > > > > > > Summary: It is implicit that you can override policies on RTCORBA::RTORB since it inherits from > > > CORBA::Object. This should be explicitly stated. > > > > > > Issue 3456: Policy overrides on RTPortableServer::POA (rt-corba-ftf) > > > > > > Summary: It is implicit that you can override policies on RTPortableServer::POA since it > > > inherits from CORBA::Object. This should be explicitly stated. X-Sender: beckwb@192.84.85.3 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 05 May 2000 00:15:38 -0400 To: Jon Currey From: Bill Beckwith Subject: Re: Issues 3454, 3455 and 3456 : Policy overrides Cc: rt-corba-ftf@omg.org, andrew@omg.org In-Reply-To: <3911FFB7.CB2178C6@highlander.com> References: <390E01E1.CFD46FB8@highlander.com> <390E31A9.D791698A@highlander.com> <4.3.1.2.20000503194054.00bb8ab0@192.84.85.3> <3911C25C.834A7485@fpk.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: 9Jishnu Mukerji wrote: >> >> Bill Beckwith wrote: >> > >> > Unresolved issues shouldn't be closed. They should be left open. >> >> Yep, no need to close issues just because there is no proposal. Some >> issues are inherently hard to address. That should not be a reason to >> lose them altogether. > >I agree that there is no reason to close an issue just because there is no >proposal. > >In this case, I am actually making a proposal, to close these issues without >making >changes to the spec. You made a proposal to my issue and did not get consensus from the group. You unilaterally changed the resolution on the issue to your proposal. >If people disagree, they can vote against my proposal, and the issues will >not be closed. I believe that a failed issue is a closed issue that will not come up in a future vote without either creating a new issue or actively reopening the closed issue. IMO you're way out of line in unilaterally picking the resolution to every issue with consensus and then forcing a quick vote. This is the first time I have seen an OMG FTF or RTF chair act in this manner. -- Bill Sender: jon Message-ID: <3975CCB3.18E02B1C@highlander.com> Date: Wed, 19 Jul 2000 11:43:47 -0400 From: Jon Currey Organization: Highlander X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "rt-corba-ftf@omg.org" , Bill Beckwith Subject: Proposals for Issues 3454, 3455 and 3456 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ; From: Bill Beckwith Subject: Re: Proposals for Issues 3454, 3455 and 3456 Cc: "rt-corba-ftf@omg.org" In-Reply-To: <3975CCB3.18E02B1C@highlander.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: @^@!!Bill, as the originator of these issues, can you confirm whether this was >or was not the intent of the issues? If there is another issue involved, or >a wider implication that I have missed, we should discuss it. I can always >modify my proposals and/or you could make alternative proposals. Yes, I'll try to do this on my plane ride this weekend and get a response to the group on Sunday or Monday. Bill Sender: jon Message-ID: <398848F0.1EA3FBEF@highlander.com> Date: Wed, 02 Aug 2000 12:14:40 -0400 From: Jon Currey Organization: Highlander X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Beckwith , "rt-corba-ftf@omg.org" CC: Jishnu Mukerji Subject: Re: Summary of current proposals ... voting soon References: <4.3.1.2.20000731124024.042f8280@192.84.85.3> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: JY]!!^''e9TQ/!!(A9!! Hi Bill Did you have a chance to re-appraise these issues, and decide whether you want to propose some changes to the spec for them? I've had another look at them, and I think that issue 3456 definitely should be closed without change : I don't think the CORBA QoS Policy framework means to imply that that you can change policies on a POA object after it has been created. Jishnu (or anyone else), do you concur? I had hoped to have this discussion resolved by now, so that we could vote on all the issues in the next few days. Can you please indicate whether you would prefer that we do or do not vote on these issues with the propsals that currently stand (my proposals to do nothing.) I will assume that you do not want us to vote on them - which means that unless we can resolve them and vote in the next few days, that there will be unresolved issues in the FTF report. I don't know how significant this is, in terms of affecting the ability to have the spec finalized from this report. Does anyone else know? Jon. Bill Beckwith wrote: > > At 11:45 PM 7/30/00, Jon Currey wrote: > > >Bill, in particular can you confirm whether or not you want some more > >discussion/want to make alternate proposals on issues 3454, 3455 and 3456? > >(As it stands, no text has been proposed for the points raised in the > >issues, and the only proposals that have been made are my proposals to > >not make any changes, for the reasons given.) > > I didn't look at email last weekend so I just saw this. > > I'll try to do this first thing in tomorrow morning. > > Bill X-Sender: beckwb@192.84.85.3 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 03 Aug 2000 16:33:55 -0400 To: Jon Currey From: Bill Beckwith Subject: Re: Issues 3454, 3455 and 3456 Cc: "rt-corba-ftf@omg.org" In-Reply-To: <398A0CF5.1F79FCEC@highlander.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: !+:e9)(m!!<3B!!0W'e9 At 08:23 PM 8/3/00, Jon Currey wrote: > >Below are the three issues that I didn't include in the vote. > >As mentioned in a previous e-mail, I have a concern on issue 3456, which >is that I have the feeling that POA's policies are meant to be immutable, >once a POA is created. (I haven't looked up the relevant text in the spec >though.) Therefore I think that the issue should be closed without changes. > >I'm not so sure on the other two issues : RTCORBA::Current in an >extension of CORBA::Current, and RTCORBA::ORB is meant to be >considered as an extension of CORBA::ORB (although the latter >relationship is not represented by inheritance in IDL, because of >CORBA::ORB being specified in PIDL.) Therefore, it seems reasonable to >say that these two types may be used to apply policy overrides >at the Current and ORB scopes, respectively. > >However, my concern is that CORBA::Object::set_policy_overrides is >specified in order to allow Object-reference level overrides on that >object reference. Wouldn't we be extending the semantics of this operation >if we said it had this other effect (setting Current or ORB scope >overrides) in the case that it is used on either of these two >(locality constrained, hopefully soon to be 'local') interfaces? > >Therefore my proposals to leave the exisiting PolicyManager and PolicyCurrent >interfaces as the sole way of setting policy overrides at these two scopes. > >Does anyone have any feeling on these subjects? Currently I haven't added >these to the issues to be voted on. Bill, would you prefer that we do or >don't vote on them? I support the proposed resolutions below. Bill >Issue 3454: Policy overrides on RTCORBA::Current >================================================ > >Summary: It is implicit that you can override policies on >RTCORBA::Current >since it inherits from CORBA::Object. This should be explicitly >stated. > >Proposed Resolution: Close this issue withougt change. There is no >reason to >use the CORBA::Object::set_policy_overrides operation on >RTCORBA::Current. >Real-Time CORBA policies are overridden at the Current scope using >the >PolicyCurrent object. > > >Issue 3455: Policy overrides on RTCORBA::RTORB >============================================== > >Summary: It is implicit that you can override policies on >RTCORBA::RTORB since >it inherits from CORBA::Object. This should be explicitly stated. > >Proposed Resolution: Close this issue withougt change. There is no >reason to >use the >CORBA::Object::set_policy_overrides operation on >RTCORBA::RTORB. Real-Time >CORBA >policies are overridden at the ORB scope using the ORB-scope >PolicyManager. > > >Issue 3456: Policy overrides on RTPortableServer::POA >===================================================== > >Summary: It is implicit that you can override policies on >RTPortableServer::POA >since it inherits from CORBA::Object. This should be explicitly >stated. > >Proposed Resolution: Close this issue withougt change. There is no >reason to >use the >CORBA::Object::set_policy_overrides operation on >RTPortableServer::POA. >Real-Time CORBA >policies, like all other policies, may be set at POA creation, and >may not >be changed >after that. Sender: jon Message-ID: <398A0CF5.1F79FCEC@highlander.com> Date: Thu, 03 Aug 2000 20:23:17 -0400 From: Jon Currey Organization: Highlander X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Beckwith , "rt-corba-ftf@omg.org" Subject: Issues 3454, 3455 and 3456 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [L!"!]Gp!!lJGe9B4W!! Below are the three issues that I didn't include in the vote. As mentioned in a previous e-mail, I have a concern on issue 3456, which is that I have the feeling that POA's policies are meant to be immutable, once a POA is created. (I haven't looked up the relevant text in the spec though.) Therefore I think that the issue should be closed without changes. I'm not so sure on the other two issues : RTCORBA::Current in an extension of CORBA::Current, and RTCORBA::ORB is meant to be considered as an extension of CORBA::ORB (although the latter relationship is not represented by inheritance in IDL, because of CORBA::ORB being specified in PIDL.) Therefore, it seems reasonable to say that these two types may be used to apply policy overrides at the Current and ORB scopes, respectively. However, my concern is that CORBA::Object::set_policy_overrides is specified in order to allow Object-reference level overrides on that object reference. Wouldn't we be extending the semantics of this operation if we said it had this other effect (setting Current or ORB scope overrides) in the case that it is used on either of these two (locality constrained, hopefully soon to be 'local') interfaces? Therefore my proposals to leave the exisiting PolicyManager and PolicyCurrent interfaces as the sole way of setting policy overrides at these two scopes. Does anyone have any feeling on these subjects? Currently I haven't added these to the issues to be voted on. Bill, would you prefer that we do or don't vote on them? Jon. Issue 3454: Policy overrides on RTCORBA::Current ================================================ Summary: It is implicit that you can override policies on RTCORBA::Current since it inherits from CORBA::Object. This should be explicitly stated. Proposed Resolution: Close this issue withougt change. There is no reason to use the CORBA::Object::set_policy_overrides operation on RTCORBA::Current. Real-Time CORBA policies are overridden at the Current scope using the PolicyCurrent object. Issue 3455: Policy overrides on RTCORBA::RTORB ============================================== Summary: It is implicit that you can override policies on RTCORBA::RTORB since it inherits from CORBA::Object. This should be explicitly stated. Proposed Resolution: Close this issue withougt change. There is no reason to use the CORBA::Object::set_policy_overrides operation on RTCORBA::RTORB. Real-Time CORBA policies are overridden at the ORB scope using the ORB-scope PolicyManager. Issue 3456: Policy overrides on RTPortableServer::POA ===================================================== Summary: It is implicit that you can override policies on RTPortableServer::POA since it inherits from CORBA::Object. This should be explicitly stated. Proposed Resolution: Close this issue withougt change. There is no reason to use the CORBA::Object::set_policy_overrides operation on RTPortableServer::POA. Real-Time CORBA policies, like all other policies, may be set at POA creation, and may not be changed after that.