Issue 3583: default priority transform (rt-corba-ftf) Source: Oracle (Mr. Jon Currey, nobody jon.currey@oracle.com) Nature: Uncategorized Issue Severity: Summary: The first paragraph on page 41 says that : 'A Real-Time ORB shall provide a default transform. Furthermore, a Real-Time ORB shall provide a mechanism to allow users to override the default priority transform with a priority transform or their own.' The second statement is true, but the first is not. (That is, we did not decide that there would be such a thing as a default priority transform.) The priority transform mechanism was specified in order to allow users to install their own modifiers to the two Real-Time CORBA Priority Models. By default, no transform is required. Therefore, I propose that we drop the first sentence, and change the second one to make its point correctly : Proposal : Change this paragraph to : 'A Real-Time ORB shall provide a mechanism to allow users to install a priority transform'. As this is a single sentence, add it to the end of the following paragraph (which actually introduces it and is therefore better before it.) Resolution: accepted Revised Text: Resolution: Drop the first sentence, and change the second one to make its point correctly : Change this paragraph to : 'A Real-Time ORB shall provide a mechanism to allow users to install a priority transform'. As this is a single sentence, add it to the end of the following paragraph (which actually introduces it and is therefore better before it.) Actions taken: April 27, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== Date: Wed, 26 Apr 2000 15:53:41 -0400 From: Jon Currey Organization: Highlander X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rt-corba-ftf@omg.org CC: jon@highlander.com Subject: New Issue : default priority transform Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ")'e9Q9O!!Df?!!gT!e9 The first paragraph on page 41 says that : 'A Real-Time ORB shall provide a default transform. Furthermore, a Real-Time ORB shall provide a mechanism to allow users to override the default priority transform with a priority transform or their own.' The second statement is true, but the first is not. (That is, we did not decide that there would be such a thing as a default priority transform.) The priority transform mechanism was specified in order to allow users to install their own modifiers to the two Real-Time CORBA Priority Models. By default, no transform is required. Therefore, I propose that we drop the first sentence, and change the second one to make its point correctly : Proposal : Change this paragraph to : 'A Real-Time ORB shall provide a mechanism to allow users to install a priority transform'. As this is a single sentence, add it to the end of the following paragraph (which actually introduces it and is therefore better before it.) Date: Thu, 27 Apr 2000 10:33:40 -0400 From: Dock Allen Organization: The MITRE Corporation X-Mailer: Mozilla 4.61 [en]C-19990607M (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon Currey CC: rt-corba-ftf@omg.org Subject: Re: New Issue : default priority transform References: <39074945.9D3A5E97@highlander.com> Content-Type: multipart/mixed; boundary="------------3B830E5D1BB7F01CA6B44819" X-UIDL: RYOe99p7!!dT]d9+C)!! I understand that there are some missteps between what the submitter team agreed to a(at least individuals' memories of what was agree upon) and what was actually passed in the spec. How should we proceed??? Do we assume that the "spec is the spec" and do finalization, as needed, to fix any problems with the spec, or do we try to reconstruct the submitters' consensus??? I suggest that it will be nearly impossible to reconstruct what the team "meant" to write... Dock Jon Currey wrote: > > The first paragraph on page 41 says that : > 'A Real-Time ORB shall provide a default transform. Furthermore, a Real-Time > ORB shall provide a mechanism to allow users to override the default priority > transform with a priority transform or their own.' > > The second statement is true, but the first is not. (That is, we did not decide > that > there would be such a thing as a default priority transform.) The priority > transform > mechanism was specified in order to allow users to install their own modifiers to > the two Real-Time CORBA Priority Models. By default, no transform is required. > Therefore, I propose that we drop the first sentence, and change the second one > to make its point correctly : > > Proposal : > Change this paragraph to : > 'A Real-Time ORB shall provide a mechanism to allow users to install a > priority transform'. > As this is a single sentence, add it to the end of the following paragraph (which > actually introduces it and is therefore better before it.) [] Dock.vcf From: "Rutt, T E (Tom)" To: Jon Currey , "'Dock Allen'" Cc: rt-corba-ftf@omg.org Subject: RE: New Issue : default priority transform Date: Thu, 27 Apr 2000 12:25:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: $)d!!)p(!!=J\!!_%)!! I think the Idea of a default transform is an implementation concern. I am sure most orbs -- Tom Rutt Lucent Technologies - Bell Labs Rm 4L-336 Tel: +1(732)949-7862 101 Crawford Corner Rd Fax: +1(732)949-1196 Holmdel NJ, 07733 USA email: terutt@lucent.com would have one, and if the user specified no overides, this would take affect. I do not think that an ORB specific default transform is a difficult thing to grasp or accept. > ---------- > From: Dock Allen[SMTP:Dock@Mitre.org] > Sent: Thursday, April 27, 2000 10:33 AM > To: Jon Currey > Cc: rt-corba-ftf@omg.org > Subject: Re: New Issue : default priority transform > > <> > I understand that there are some missteps between what the submitter > team agreed to a(at least individuals' memories of what was agree upon) > and what was actually passed in the spec. How should we proceed??? > > Do we assume that the "spec is the spec" and do finalization, as needed, > to fix any problems with the spec, or do we try to reconstruct the > submitters' consensus??? > > I suggest that it will be nearly impossible to reconstruct what the team > "meant" to write... > > Dock > > Jon Currey wrote: > > > > The first paragraph on page 41 says that : > > 'A Real-Time ORB shall provide a default transform. Furthermore, a > Real-Time > > ORB shall provide a mechanism to allow users to override the default > priority > > transform with a priority transform or their own.' > > > > The second statement is true, but the first is not. (That is, we did not > decide > > that > > there would be such a thing as a default priority transform.) The > priority > > transform > > mechanism was specified in order to allow users to install their own > modifiers to > > the two Real-Time CORBA Priority Models. By default, no transform is > required. > > Therefore, I propose that we drop the first sentence, and change the > second one > > to make its point correctly : > > > > Proposal : > > Change this paragraph to : > > 'A Real-Time ORB shall provide a mechanism to allow users to install a > > priority transform'. > > As this is a single sentence, add it to the end of the following > paragraph (which > > actually introduces it and is therefore better before it.) > Date: Thu, 27 Apr 2000 13:17:23 -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: Dock Allen Cc: Jon Currey , rt-corba-ftf@omg.org Subject: Re: New Issue : default priority transform References: <39074945.9D3A5E97@highlander.com> <39084FC4.52B7B460@Mitre.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: L<-!!B)6e9CWSd9&^ > I understand that there are some missteps between what the submitter > team agreed to a(at least individuals' memories of what was agree upon) > and what was actually passed in the spec. How should we proceed??? > > Do we assume that the "spec is the spec" and do finalization, as needed, > to fix any problems with the spec, or do we try to reconstruct the > submitters' consensus??? > > I suggest that it will be nearly impossible to reconstruct what the team > "meant" to write... Strictly speaking, we are fixing up the adopted spec. However, if a proposer of a fix chooses to cite records from submitters meetings as evidence in support of his/her position on a particular matter, that is his or her prerogative, and then we can argue about whether we agree with the position or not, and whether we consider the evidence cited as relevant/important or not. Jishnu. > Jon Currey wrote: > > > > The first paragraph on page 41 says that : > > 'A Real-Time ORB shall provide a default transform. Furthermore, a Real-Time > > ORB shall provide a mechanism to allow users to override the default priority > > transform with a priority transform or their own.' > > > > The second statement is true, but the first is not. (That is, we did not decide > > that > > there would be such a thing as a default priority transform.) The priority > > transform > > mechanism was specified in order to allow users to install their own modifiers to > > the two Real-Time CORBA Priority Models. By default, no transform is required. > > Therefore, I propose that we drop the first sentence, and change the second one > > to make its point correctly : > > > > Proposal : > > Change this paragraph to : > > 'A Real-Time ORB shall provide a mechanism to allow users to install a > > priority transform'. > > As this is a single sentence, add it to the end of the following paragraph (which > > actually introduces it and is therefore better before it.) I tend to agree with that position. If a vendor is stupid enough to produce a product that core dumps when someone tries to exercise the transform interface without installing a transform, then said vendor desrves everything that they will get from the customers.:-) Standards should not have to save vendors from their own stupidity.:-) Jishnu. Sender: jon Message-ID: <390E4F1D.C31A1FA3@highlander.com> Date: Mon, 01 May 2000 23:44:29 -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: "Rutt, T E (Tom)" , Jishnu Mukerji , rt-corba-ftf@omg.org Subject: Re: New Issue : default priority transform References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: (#ld92TBe9QiQd9D`T!! Just to clarify the situation with regard to the idea of a default Priority Transform ... The Priority Transform was conceived as an additional mechanism to allow the user to vary the RTCORBA::Priority value associated with an invocation from the value that would be used according to the Priority Model that the CORBA Object involved was configured to use. It is different to a Priority Mapping, which is a necessary component of the Real-Time CORBA runtime. We chose to mandate that a default Priority Mapping be provided with a Real-Time CORBA ORB, but not to presecribe what that Mapping should be. This was done for practical reasons : Although it is anticipated that the default Priority Mapping will often need to be replaced with a custom Mapping, suited to the needs of the particluar application, having a default Mapping allows the user to start developing Real-Time CORBA applications 'out of the box', and defer learning about custom Mappings and hence makes the learning curve more gentle. A corresponding situation does not exist for Priority Transforms. Not having a Priority Transform installed is something like not having any interceptors installed. The product should not crash, and there should be no need to install a 'null' Transform. (Doing so would add unnecessary method calls to the code path of an invocation when one or other of the 'vanilla' Priority Models iss desired.) Hence the proposal to replace the text about providing a default Transform with text about there being none installed by default, with an API being provided to install one. (I believe that this text only entered the document because I cut and paste text from the Priority Mapping section to create the first draft of the Priority Transform section.) Jon. "Rutt, T E (Tom)" wrote: > > I think the Idea of a default transform is an implementation concern. I am > sure most orbs would have one, and if the user specified no overides, this would > take affect. > > I do not think that an ORB specific default transform is a difficult thing > to grasp or accept. > Jishnu Mukerji wrote: ... > > > Proposal : > > > Change this paragraph to : > > > 'A Real-Time ORB shall provide a mechanism to allow users to install a > > > priority transform'. > > > As this is a single sentence, add it to the end of the following paragraph (which > > > actually introduces it and is therefore better before it.) > > I tend to agree with that position. If a vendor is stupid enough to > produce a product that core dumps when someone tries to exercise the > transform interface without installing a transform, then said vendor > desrves everything that they will get from the customers.:-) Standards > should not have to save vendors from their own stupidity.:-) X-Sender: beckwb@192.84.85.3 X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 02 May 2000 12:14:58 -0400 To: Jon Currey From: Bill Beckwith Subject: Re: New Issue : default priority transform Cc: "Rutt, T E (Tom)" , Jishnu Mukerji , rt-corba-ftf@omg.org In-Reply-To: <390E4F1D.C31A1FA3@highlander.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: \/!e9h!9!!cp?e9kd=!! At 11:44 PM 5/1/00, Jon Currey wrote: > >Just to clarify the situation with regard to the idea of a default Priority >Transform ... > >The Priority Transform was conceived as an additional mechanism to allow the >user to vary the RTCORBA::Priority value associated with an invocation from >the value that would be used according to the Priority Model that the CORBA >Object involved was configured to use. Check. >It is different to a Priority Mapping, which is a necessary component of the >Real-Time CORBA runtime. > >We chose to mandate that a default Priority Mapping be provided with a >Real-Time CORBA ORB, but not to presecribe what that Mapping should be. This >was done for practical reasons : Although it is anticipated that the default >Priority Mapping will often need to be replaced with a custom Mapping, suited >to the needs of the particluar application, having a default Mapping allows >the user to start developing Real-Time CORBA applications 'out of the box', >and defer learning about custom Mappings and hence makes the learning curve >more gentle. Check. >A corresponding situation does not exist for Priority Transforms. Not having a >Priority Transform installed is something like not having any interceptors >installed. The product should not crash, and there should be no need to >install a 'null' Transform. (Doing so would add unnecessary method calls to >the code path of an invocation when one or other of the 'vanilla' Priority >Models iss desired.) I think you are getting to bogged down by implementation details. I suggest that the specification just have text something like: A Real-Time ORB compliant with this specification shall not by default transform the Real-Time CORBA priority of incoming requests. IMO, how the implementation achieves this (non-) effect is an implementation detail. >Hence the proposal to replace the text about providing a default Transform >with text about there being none installed by default, with an API being >provided to install one. (I believe that this text only entered the document >because I cut and paste text from the Priority Mapping section to create the >first draft of the Priority Transform section.) -- Bill Sender: jon Message-ID: <3975EEA6.12687044@highlander.com> Date: Wed, 19 Jul 2000 14:08:38 -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" Subject: Proposal for Issue 3583 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~PV!!5Ae!!+Yid9)?1e9 Issue 3583: default priority transform (rt-corba-ftf) Summary: The first paragraph on page 41 says that : 'A Real-Time ORB shall provide a default transform. Furthermore, a Real-Time ORB shall provide a mechanism to allow users to override the default priority transform with a priority transform or their own.' The second statement is true, but the first is not. (That is, we did not decide that there would be such a thing as a default priority transform.) The priority transform mechanism was specified in order to allow users to install their own modifiers to the twoReal-Time CORBA Priority Models. By default, no transform is required. Therefore, I propose that we drop the first sentence, and change the second one to make its point correctly : Proposal : Change this paragraph to : 'A Real-Time ORB shall provide a mechanism to allow users to install a priority transform'. As this is a single sentence, add it to the end of the following paragraph (which actually introduces it and is therefore better before it.) Jon. Date: Mon, 31 Jul 2000 09:32:52 -0400 From: "Barker, Thomas" Subject: RE: Summary of current proposals ... voting soon - Issue 3583 def ault priority Xform To: rt-corba-ftf@omg.org Message-id: <99AA2270B1E6D111BCE10000F805F17F043EB370@EMSS35M02> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-transfer-encoding: 7BIT Content-Type: text/plain X-UIDL: F!T!!A(=!!WG5!!OMXd9 I reviewed the proposed changes and wonder about the suggested fix for 3583. The spec calls for implementors to provide a default priority transformation and the the proposed fix is eliminating that requirement. To me it seems that the default is required, otherwise what does a transform-request return when no transform function has been defined? I'm sure their must be some exception that could be used, but I don't remember it being specified in the spec. If we eliminate the default isn't there another change required to specify the exception? I actually prefer the default behavior to the exception. Consider two situations. For initial users not providing the default means that they must introduce both the transform and its invoking statements concurrently. When the new user does not do this and instead writes a syntactically correct transform-request that yields an exception I expect they will abandon the effort and assume their ORB vendor does not implement priority transforms the way the spec says it is suppose to be done. Nothing else about ORBs is consistent enough to make the user believe the ORB was good and he was faulty. I also envision pulling code from one application to another and in doing so removing the code from the environment where a transform was specified. In such situations default behavior keeps the development progressing while funny exceptions stop everything while somebody goes to find the book and search for the causative statements. (I've always found that funny exceptions happen shortly before critical development deadlines and they then take hours to understand and resolve. Shortly before a release deadline is exactly when I don't have hours. Conversely, default behavior generally screws up performance and while I'm doing performance tuning I normally have lots of time.) > -----Original Message----- > From: Jon Currey [SMTP:jon@highlander.com] > Sent: Sunday, July 30, 2000 11:46 PM > To: rt-corba-ftf@omg.org; Bill Beckwith > Subject: Summary of current proposals ... voting soon > > > Below is a list of the outstanding issues, along with the resolutions that > have been proposed. > > I'd like to start a vote on the proposals for all issues in a few days > time. > I was thinking of starting the vote on Thursday (August 3rd), and allowing > 7 days for voting (so finishing on Wednesday 9th), to allow time to > prepare > the report before the deadline on the 14th. > > Therefore, could everyone please take a look at the issues and proposals > now, to see if any discussion is needed on any of them. > > 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.) > > Jon. << File: ftf.txt >> Sender: jon Message-ID: <3985CE91.8EE31E41@highlander.com> Date: Mon, 31 Jul 2000 15:08:01 -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: "Barker, Thomas" CC: rt-corba-ftf@omg.org Subject: Re: Summary of current proposals ... voting soon - Issue 3583 default priority Xform References: <99AA2270B1E6D111BCE10000F805F17F043EB370@EMSS35M02> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: BgNd9K3Z!!%_p!!4%!e9 Hi Tom "Barker, Thomas" wrote: > > I reviewed the proposed changes and wonder about the suggested fix for 3583. > The spec calls for implementors to provide a default priority transformation > and the the proposed fix is eliminating that requirement. To me it seems > that the default is required, otherwise what does a transform-request return > when no transform function has been defined? You're assuming that there always has to be a Priority Transform installed. The only piece of text in the spec that supports this is the sentence that I want to remove : 'A Real-Time ORB shall provide a default transform.' The wording of the rest of the section on Priority Transforms is aligned with what I believe was the intended behaviour. i.e. that Priority Transforms are _optional modifiers_ to the priority on the server-side of CORBA invocations. The idea is that if the user does not install a Priority Mapping, the priority that is used is the unmodified priority that is appropriate at that point. (Obtained either from the service context passed with the invocation, or locally, depending on the Priority Model in use for that object.) Hence we have the following wording (with my emphases) : 'Real-Time CORBA supports the installation of _user-defined_ Priority Transforms ...' 'Use of these Priority Transforms allows application designers to implement Real-Time CORBA systems using priority models different from either the Client Propagated or Server Declared priority models ...' 'Priority Transforms are _user-provided_ functions ...' > > I'm sure their must be some exception that could be used, but I > don't > remember it being specified in the spec. If we eliminate the > default isn't > there another change required to specify the exception? No. The semantics can be that if there is no Priority Transform installed (which would be the default), then no calls are made to the priority transform methods. Hence no need to talk about exceptions. > > I actually prefer the default behavior to the exception. (The rest of your comments were predicated on their being an exception raised if a Transform isn't installed.) The key point is that there doesn't always have to be a Priority Transform installed, and that by default (unless the user installs one), there won't be one installed, and the ORB won't try and use one. The alternative would be to make the following changes to the spec : - define a default Priority Transform - mandate that there always has to be a Priority Transform installed. But this seems pointless : what would the default Priority Transform do? Surely it would have to leave the priority the same (untransformed.) Its seems a lot clearer (and simpler) to me to just say that absence of a Transform leaves the priority untransformed, rather than talking about a default transform that does nothing. What do you think? By the way, in case anyone is wondering why these words about a default Transform are in the current version of the document, and hence how much of a change from the original intention this is. The answer is : I wrote this section, at the behest of the submission group, in the last 48 hours before we submitted the final submission. I based the text for this section on the section on Prority Mappings. I cut and pasted the text, including the text about there being a default Priority Mapping, and just changed the words to Priority Transform. Thus these words got there by accident rather than design. Then, due to the short time before the submission deadline, we didn't give the new section much scrutiny. Note : Having a default Priority Mapping is a quite different issue, and makes sense, given the purpose of a Priority Mapping. There needs to always be exactly one Priority Mapping installed, to map between native and CORBA priorities. Jon. > > > -----Original Message----- > > From: Jon Currey [SMTP:jon@highlander.com] > > Sent: Sunday, July 30, 2000 11:46 PM > > To: rt-corba-ftf@omg.org; Bill Beckwith > > Subject: Summary of current proposals ... voting soon > > > > > > Below is a list of the outstanding issues, along with the resolutions that > > have been proposed. > > > > I'd like to start a vote on the proposals for all issues in a few days > > time. > > I was thinking of starting the vote on Thursday (August 3rd), and allowing > > 7 days for voting (so finishing on Wednesday 9th), to allow time to > > prepare > > the report before the deadline on the 14th. > > > > Therefore, could everyone please take a look at the issues and proposals > > now, to see if any discussion is needed on any of them. > > > > 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.) > > > > Jon. << File: ftf.txt >>