Issue 3775: Policy split (OTSPolicy & InvocationPolicy) (ots-rtf) Source: ZeroC (Mr. Bernard Normier, bernard(at)zeroc.com) Nature: Uncategorized Issue Severity: Summary: Ram, Tom, all, My main concern regarding the introduction of these two policies is interoperability and source-code portability between "OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're working on. "OTS 1.1 + messaging updates" is a real adopted spec, not a working draft. The (adopted) messaging spec refers to it. And I know at least one shipping implementation of this OTS revision. So far each new OTS revision (including "OTS 1.1 + messaging updates") has addressed interoperability with earlier revisions; I think that it would not be wise to adopt a proposal that does not address this concern. Also, the question asked by issue #3425 is "what shall I do when on the client-side I get an IOR with no transaction policy component?". Does the introduction of these new policies really help answering this question? Maybe treating this as a separate issue would help solve issue #3425. Resolution: Revised Text: Actions taken: August 18, 2000: received issue Discussion: End of Annotations:===== From: "Bernard Normier" To: Subject: Policy split (OTSPolicy & InvocationPolicy) Date: Fri, 18 Aug 2000 10:35:11 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text X-UIDL: ajbd9U]!!!=HR!!&N1!! Ram, Tom, all, My main concern regarding the introduction of these two policies is interoperability and source-code portability between "OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're working on. "OTS 1.1 + messaging updates" is a real adopted spec, not a working draft. The (adopted) messaging spec refers to it. And I know at least one shipping implementation of this OTS revision. So far each new OTS revision (including "OTS 1.1 + messaging updates") has addressed interoperability with earlier revisions; I think that it would not be wise to adopt a proposal that does not address this concern. Also, the question asked by issue #3425 is "what shall I do when on the client-side I get an IOR with no transaction policy component?". Does the introduction of these new policies really help answering this question? Maybe treating this as a separate issue would help solve issue #3425. Cheers, Bernard Date: Fri, 18 Aug 2000 13:29:45 -0700 From: Blake Biesecker To: Bernard Normier Cc: ots-rtf@omg.org Subject: Re: Policy split (OTSPolicy & InvocationPolicy) Message-ID: <20000818132945.F29813@gemstone.com> References: <008a01c00921$84343a80$6a85413f@boston.amer.iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <008a01c00921$84343a80$6a85413f@boston.amer.iona.com>; from bernard.normier@iona.com on Fri, Aug 18, 2000 at 10:35:11AM -0400 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: \EK!!'P&!!=!id9jo_d9 Bernard brings up a valid point. Ed's proposal, while it seems to have more general support, does not address this very important issue. I think it is easily fixed by just keeping the old TransactionPolicies for backwards compatibility and retaining the mapping that Ed currently has in place. On Fri, Aug 18, 2000 at 10:35:11AM -0400, Bernard Normier wrote: > Ram, Tom, all, > > My main concern regarding the introduction of these two policies > is interoperability and source-code portability between > "OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're > working on. > > "OTS 1.1 + messaging updates" is a real adopted spec, not a working > draft. The (adopted) messaging spec refers to it. And I know at least > one shipping implementation of this OTS revision. > > So far each new OTS revision (including "OTS 1.1 + messaging updates") > has addressed interoperability with earlier revisions; I think > that it would not be wise to adopt a proposal that does not address > this concern. > > Also, the question asked by issue #3425 is "what shall I do when on > the client-side I get an IOR with no transaction policy component?". > Does the introduction of these new policies really help answering > this question? Maybe treating this as a separate issue would help > solve issue #3425. > We are definitely not going to be able to tackle all of the issues brought up around 3425. The goal is to vote as soon as possible on something that can be implemented and that is backward compatible. Improvements and smaller issues will need to be resolved at a later date. Blake > > Cheers, > > Bernard > > Date: Fri, 18 Aug 2000 17:05:29 -0400 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Blake Biesecker Cc: Bernard Normier , ots-rtf@omg.org Subject: Re: Policy split (OTSPolicy & InvocationPolicy) References: <008a01c00921$84343a80$6a85413f@boston.amer.iona.com> > <20000818132945.F29813@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Ti-!!BEFe9[lMe9=8X!! Blake Biesecker wrote: > > Bernard brings up a valid point. Ed's proposal, while it seems > to have more general support, does not address this very > important issue. I think it is easily fixed by just keeping > the old TransactionPolicies for backwards compatibility and > retaining the mapping that Ed currently has in place. I thought that was always the plan. That is what I had tried to explain in a screed about backward compatibly adding new Policies, way back when. When did that plan change? Jishnu. Date: Fri, 18 Aug 2000 14:16:00 -0700 From: Blake Biesecker To: Jishnu Mukerji Cc: Bernard Normier , ots-rtf@omg.org Subject: Re: Policy split (OTSPolicy & InvocationPolicy) Message-ID: <20000818141600.H29813@gemstone.com> References: <008a01c00921$84343a80$6a85413f@boston.amer.iona.com> <20000818132945.F29813@gemstone.com> <399DA519.2C99DFDB@fpk.hp.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <399DA519.2C99DFDB@fpk.hp.com>; from jis@fpk.hp.com on Fri, Aug 18, 2000 at 05:05:29PM -0400 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: #^#!!@W&!![Wi!!%5/!! On Fri, Aug 18, 2000 at 05:05:29PM -0400, Jishnu Mukerji wrote: > Blake Biesecker wrote: > > > > Bernard brings up a valid point. Ed's proposal, while it seems > > to have more general support, does not address this very > > important issue. I think it is easily fixed by just keeping > > the old TransactionPolicies for backwards compatibility and > > retaining the mapping that Ed currently has in place. > > I thought that was always the plan. That is what I had tried to explain > in a screed about backward compatibly adding new Policies, way back > when. When did that plan change? > > Jishnu. > Ed took it out for some reason. Easy enough to put back in. Blake From: "Bernard Normier" To: "Blake Biesecker" , "Jishnu Mukerji" Cc: References: <008a01c00921$84343a80$6a85413f@boston.amer.iona.com> <20000818132945.F29813@gemstone.com> <399DA519.2C99DFDB@fpk.hp.com> <20000818141600.H29813@gemstone.com> Subject: Re: Policy split (OTSPolicy & InvocationPolicy) Date: Fri, 18 Aug 2000 19:49:19 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text X-UIDL: -K"!!K'"!!YBF!!]2Ud9 By itself, keeping the old transaction policy values and transaction policy component is not sufficient to achieve interoperability between "OTS + messaging" and this new OTS 1.2. For example an "OTS + messaging" client won't be able to use an OTS 1.2 server that only adds the new OTSPolicy-component and InvocationPolicy-component to its IORs. So, for interoperability, does an OTS 1.2 server have to add transaction-policy components to its IORs? Similarly, is an OTS 1.2 client expected to understand IORs that come with an "OTS + messaging" transaction-policy component? Cheers, Bernard ----- Original Message ----- From: "Blake Biesecker" To: "Jishnu Mukerji" Cc: "Bernard Normier" ; Sent: Friday, August 18, 2000 5:16 PM Subject: Re: Policy split (OTSPolicy & InvocationPolicy) > On Fri, Aug 18, 2000 at 05:05:29PM -0400, Jishnu Mukerji wrote: > > Blake Biesecker wrote: > > > > > > Bernard brings up a valid point. Ed's proposal, while it seems > > > to have more general support, does not address this very > > > important issue. I think it is easily fixed by just keeping > > > the old TransactionPolicies for backwards compatibility and > > > retaining the mapping that Ed currently has in place. > > > > I thought that was always the plan. That is what I had tried to explain > > in a screed about backward compatibly adding new Policies, way back > > when. When did that plan change? > > > > Jishnu. > > > > Ed took it out for some reason. Easy enough to put back in. > > Blake > Date: Fri, 18 Aug 2000 18:23:26 -0700 From: Blake Biesecker To: Bernard Normier Cc: Jishnu Mukerji , ots-rtf@omg.org Subject: Re: Policy split (OTSPolicy & InvocationPolicy) Message-ID: <20000818182325.D15091@gemstone.com> References: <008a01c00921$84343a80$6a85413f@boston.amer.iona.com> <20000818132945.F29813@gemstone.com> <399DA519.2C99DFDB@fpk.hp.com> <20000818141600.H29813@gemstone.com> <016e01c0096e$effcd270$6a85413f@boston.amer.iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <016e01c0096e$effcd270$6a85413f@boston.amer.iona.com>; from bernard.normier@iona.com on Fri, Aug 18, 2000 at 07:49:19PM -0400 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: @92!!eWn!!a'1e9cP0!! Bernard, I think we should deal with those issues separately. We can open another issue and extra text as needed in a separate proposal. Blake On Fri, Aug 18, 2000 at 07:49:19PM -0400, Bernard Normier wrote: > By itself, keeping the old transaction policy values and transaction > policy component is not sufficient to achieve interoperability > between "OTS + messaging" and this new OTS 1.2. > > For example an "OTS + messaging" client won't be able to use an > OTS 1.2 server that only adds the new OTSPolicy-component and > InvocationPolicy-component to its IORs. So, for interoperability, > does an OTS 1.2 server have to add transaction-policy components > to its IORs? > > Similarly, is an OTS 1.2 client expected to understand IORs that > come with an "OTS + messaging" transaction-policy component? > > Cheers, > > Bernard > > ----- Original Message ----- > From: "Blake Biesecker" > To: "Jishnu Mukerji" > Cc: "Bernard Normier" ; > Sent: Friday, August 18, 2000 5:16 PM > Subject: Re: Policy split (OTSPolicy & InvocationPolicy) > > > > On Fri, Aug 18, 2000 at 05:05:29PM -0400, Jishnu Mukerji wrote: > > > Blake Biesecker wrote: > > > > > > > > Bernard brings up a valid point. Ed's proposal, while it seems > > > > to have more general support, does not address this very > > > > important issue. I think it is easily fixed by just keeping > > > > the old TransactionPolicies for backwards compatibility and > > > > retaining the mapping that Ed currently has in place. > > > > > > I thought that was always the plan. That is what I had tried to explain > > > in a screed about backward compatibly adding new Policies, way back > > > when. When did that plan change? > > > > > > Jishnu. > > > > > > > Ed took it out for some reason. Easy enough to put back in. > > > > Blake > > > > X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 21 Aug 2000 12:19:46 -0700 To: Blake Biesecker , Bernard Normier From: Edward Cobb Subject: Re: Policy split (OTSPolicy & InvocationPolicy) Cc: ots-rtf@omg.org In-Reply-To: <20000818132945.F29813@gemstone.com> References: <008a01c00921$84343a80$6a85413f@boston.amer.iona.com> <008a01c00921$84343a80$6a85413f@boston.amer.iona.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: "H=!!R40e9CDfd95Idd9 Deleting the current TransactionPolicy definitions were a mistake by the editor. I can easily undo the change if you'd like but I've been waiting to see if other clarifications should also be made. At 01:29 PM 8/18/00 -0700, Blake Biesecker wrote: >Bernard brings up a valid point. Ed's proposal, while it seems >to have more general support, does not address this very >important issue. I think it is easily fixed by just keeping >the old TransactionPolicies for backwards compatibility and >retaining the mapping that Ed currently has in place. > >On Fri, Aug 18, 2000 at 10:35:11AM -0400, Bernard Normier wrote: >> Ram, Tom, all, >> >> My main concern regarding the introduction of these two policies >> is interoperability and source-code portability between >> "OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're >> working on. >> >> "OTS 1.1 + messaging updates" is a real adopted spec, not a working >> draft. The (adopted) messaging spec refers to it. And I know at least >> one shipping implementation of this OTS revision. >> >> So far each new OTS revision (including "OTS 1.1 + messaging updates") >> has addressed interoperability with earlier revisions; I think >> that it would not be wise to adopt a proposal that does not address >> this concern. >> >> Also, the question asked by issue #3425 is "what shall I do when on >> the client-side I get an IOR with no transaction policy component?". >> Does the introduction of these new policies really help answering >> this question? Maybe treating this as a separate issue would help >> solve issue #3425. >> > >We are definitely not going to be able to tackle all of the issues >brought up around 3425. The goal is to vote as soon as possible >on something that can be implemented and that is backward >compatible. Improvements and smaller issues will need to be >resolved at a later date. > >Blake > > >> >> Cheers, >> >> Bernard >> >> > > ************************************************************** Ed Cobb, Vice President, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 21 Aug 2000 12:34:05 -0700 To: jis@fpk.hp.com, Blake Biesecker From: Edward Cobb Subject: Re: Policy split (OTSPolicy & InvocationPolicy) Cc: Bernard Normier , ots-rtf@omg.org In-Reply-To: <399DA519.2C99DFDB@fpk.hp.com> References: <008a01c00921$84343a80$6a85413f@boston.amer.iona.com> <20000818132945.F29813@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: O^8e9TQ)e905!"!Sg&e9 When the editor screwed up :-) At 05:05 PM 8/18/00 -0400, Jishnu Mukerji wrote: >Blake Biesecker wrote: >> >> Bernard brings up a valid point. Ed's proposal, while it seems >> to have more general support, does not address this very >> important issue. I think it is easily fixed by just keeping >> the old TransactionPolicies for backwards compatibility and >> retaining the mapping that Ed currently has in place. > >I thought that was always the plan. That is what I had tried to explain >in a screed about backward compatibly adding new Policies, way back >when. When did that plan change? > >Jishnu. > > ************************************************************** Ed Cobb, Vice President, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 E-mail: ed.cobb@beasys.com ************************************************************** Date: Wed, 1 Nov 2000 17:44:01 -0800 From: Blake Biesecker To: bernard.normier@iona.com Cc: ots-rtf@emerald.omg.org Subject: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) Message-ID: <20001101174400.G22453@gemstone.com> References: <4.2.0.58.20000823164230.00a25ba0@emerald.omg.org> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <4.2.0.58.20000823164230.00a25ba0@emerald.omg.org>; from juergen@omg.org on Wed, Aug 23, 2000 at 04:43:19PM -0400 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: ?PJe9DC2!![C&!!U-Td9 Bernard, I'm assuming that this issue is addressed by 3425 and 3991. Please let me know if you disagree. Blake On Wed, Aug 23, 2000 at 04:43:19PM -0400, Juergen Boldt wrote: > This is issue # 3775 "Bernard Normier" > > Policy split (OTSPolicy & InvocationPolicy) > > Ram, Tom, all, > > My main concern regarding the introduction of these two policies > is interoperability and source-code portability between > "OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're > working on. > > "OTS 1.1 + messaging updates" is a real adopted spec, not a working > draft. The (adopted) messaging spec refers to it. And I know at least > one shipping implementation of this OTS revision. > > So far each new OTS revision (including "OTS 1.1 + messaging updates") > has addressed interoperability with earlier revisions; I think > that it would not be wise to adopt a proposal that does not address > this concern. > > Also, the question asked by issue #3425 is "what shall I do when on > the client-side I get an IOR with no transaction policy component?". > Does the introduction of these new policies really help answering > this question? Maybe treating this as a separate issue would help > solve issue #3425. > > > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > > > > ================================================================ From: "Bernard Normier" To: "Blake Biesecker" Cc: References: <4.2.0.58.20000823164230.00a25ba0@emerald.omg.org> <20001101174400.G22453@gemstone.com> Subject: Re: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) Date: Thu, 2 Nov 2000 11:40:37 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text X-UIDL: To: Cc: Sent: Wednesday, November 01, 2000 8:44 PM Subject: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) > Bernard, > > I'm assuming that this issue is addressed by 3425 and 3991. > Please let me know if you disagree. > > Blake > > On Wed, Aug 23, 2000 at 04:43:19PM -0400, Juergen Boldt wrote: > > This is issue # 3775 "Bernard Normier" > > > > Policy split (OTSPolicy & InvocationPolicy) > > > > Ram, Tom, all, > > > > My main concern regarding the introduction of these two policies > > is interoperability and source-code portability between > > "OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're > > working on. > > > > "OTS 1.1 + messaging updates" is a real adopted spec, not a >working > > draft. The (adopted) messaging spec refers to it. And I know at >least > > one shipping implementation of this OTS revision. > > > > So far each new OTS revision (including "OTS 1.1 + messaging >updates") > > has addressed interoperability with earlier revisions; I think > > that it would not be wise to adopt a proposal that does not >address > > this concern. > > > > Also, the question asked by issue #3425 is "what shall I do when >on > > the client-side I get an IOR with no transaction policy >component?". > > Does the introduction of these new policies really help answering > > this question? Maybe treating this as a separate issue would help > > solve issue #3425. > > > > > > > > ================================================================ > > > > Juergen Boldt > > Senior Member of Technical Staff > > > > Object Management Group Tel. +1-781 444 0404 ext. 132 > > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > > Needham, MA 02494, USA Email: juergen@omg.org > > > > > > > > ================================================================ > Date: Thu, 2 Nov 2000 11:42:11 -0800 From: Blake Biesecker To: Bernard Normier Cc: ots-rtf@emerald.omg.org Subject: Re: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) Message-ID: <20001102114210.E23041@gemstone.com> References: <4.2.0.58.20000823164230.00a25ba0@emerald.omg.org> <20001101174400.G22453@gemstone.com> <00c601c044eb$a0e2b7f0$4985413f@boston.amer.iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <00c601c044eb$a0e2b7f0$4985413f@boston.amer.iona.com>; from bernard.normier@iona.com on Thu, Nov 02, 2000 at 11:40:37AM -0500 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: @eXd97=;!!>8?e9M,9!! What is insufficient about keeping the TransactionPolicy idl in for backward compatibility and mapping the old policies to the new? Are you interested in offering up a proposal to clarify the spec? Blake On Thu, Nov 02, 2000 at 11:40:37AM -0500, Bernard Normier wrote: > No, the resolutions to issues 3425 and 3991 did not address > interoperability with "OTS 1.1 + messaging updates". > > Regards, > > Bernard > ----- Original Message ----- > From: "Blake Biesecker" > To: > Cc: > Sent: Wednesday, November 01, 2000 8:44 PM > Subject: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) > > > > Bernard, > > > > I'm assuming that this issue is addressed by 3425 and 3991. > > Please let me know if you disagree. > > > > Blake > > > > On Wed, Aug 23, 2000 at 04:43:19PM -0400, Juergen Boldt wrote: > > > This is issue # 3775 "Bernard Normier" > > > > > > Policy split (OTSPolicy & InvocationPolicy) > > > > > > Ram, Tom, all, > > > > > > My main concern regarding the introduction of these two policies > > > is interoperability and source-code portability between > > > "OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're > > > working on. > > > > > > "OTS 1.1 + messaging updates" is a real adopted spec, not a working > > > draft. The (adopted) messaging spec refers to it. And I know at least > > > one shipping implementation of this OTS revision. > > > > > > So far each new OTS revision (including "OTS 1.1 + messaging updates") > > > has addressed interoperability with earlier revisions; I think > > > that it would not be wise to adopt a proposal that does not address > > > this concern. > > > > > > Also, the question asked by issue #3425 is "what shall I do when on > > > the client-side I get an IOR with no transaction policy component?". > > > Does the introduction of these new policies really help answering > > > this question? Maybe treating this as a separate issue would help > > > solve issue #3425. > > > > > > > > > > > > ================================================================ > > > > > > Juergen Boldt > > > Senior Member of Technical Staff > > > > > > Object Management Group Tel. +1-781 444 0404 ext. 132 > > > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > > > Needham, MA 02494, USA Email: juergen@omg.org > > > > > > > > > > > > ================================================================ > > > > Date: Thu, 2 Nov 2000 15:10:59 -0800 From: Blake Biesecker To: Bernard Normier Cc: ots-rtf@emerald.omg.org Subject: Re: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) Message-ID: <20001102151059.K23041@gemstone.com> References: <4.2.0.58.20000823164230.00a25ba0@emerald.omg.org> <20001101174400.G22453@gemstone.com> <00c601c044eb$a0e2b7f0$4985413f@boston.amer.iona.com> <20001102114210.E23041@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <20001102114210.E23041@gemstone.com>; from blakeb@gemstone.com on Thu, Nov 02, 2000 at 11:42:11AM -0800 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: A]p!!Nm;e9nN What is insufficient about keeping the TransactionPolicy idl > in for backward compatibility and mapping the old policies > to the new? > > Are you interested in offering up a proposal to clarify > the spec? > > Blake > > On Thu, Nov 02, 2000 at 11:40:37AM -0500, Bernard Normier wrote: > > No, the resolutions to issues 3425 and 3991 did not address > > interoperability with "OTS 1.1 + messaging updates". > > > > Regards, > > > > Bernard > > ----- Original Message ----- > > From: "Blake Biesecker" > > To: > > Cc: > > Sent: Wednesday, November 01, 2000 8:44 PM > > Subject: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) > > > > > > > Bernard, > > > > > > I'm assuming that this issue is addressed by 3425 and 3991. > > > Please let me know if you disagree. > > > > > > Blake > > > > > > On Wed, Aug 23, 2000 at 04:43:19PM -0400, Juergen Boldt wrote: > > > > This is issue # 3775 "Bernard Normier" > > > > > > > > Policy split (OTSPolicy & InvocationPolicy) > > > > > > > > Ram, Tom, all, > > > > > > > > My main concern regarding the introduction of these two policies > > > > is interoperability and source-code portability between > > > > "OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're > > > > working on. > > > > > > > > "OTS 1.1 + messaging updates" is a real adopted spec, not a working > > > > draft. The (adopted) messaging spec refers to it. And I know at least > > > > one shipping implementation of this OTS revision. > > > > > > > > So far each new OTS revision (including "OTS 1.1 + messaging updates") > > > > has addressed interoperability with earlier revisions; I think > > > > that it would not be wise to adopt a proposal that does not address > > > > this concern. > > > > > > > > Also, the question asked by issue #3425 is "what shall I do when on > > > > the client-side I get an IOR with no transaction policy component?". > > > > Does the introduction of these new policies really help answering > > > > this question? Maybe treating this as a separate issue would help > > > > solve issue #3425. > > > > > > > > > > > > > > > > ================================================================ > > > > > > > > Juergen Boldt > > > > Senior Member of Technical Staff > > > > > > > > Object Management Group Tel. +1-781 444 0404 ext. 132 > > > > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > > > > Needham, MA 02494, USA Email: juergen@omg.org > > > > > > > > > > > > > > > > ================================================================ > > > > > > > From: "Bernard Normier" To: "Blake Biesecker" Cc: References: <4.2.0.58.20000823164230.00a25ba0@emerald.omg.org> <20001101174400.G22453@gemstone.com> <00c601c044eb$a0e2b7f0$4985413f@boston.amer.iona.com> <20001102114210.E23041@gemstone.com> <20001102151059.K23041@gemstone.com> Subject: Re: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) Date: Thu, 2 Nov 2000 18:42:18 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text X-UIDL: jYTd9ND~e9b0Je928i!! Blake, Keeping the old IDL and defining a satisfactory mapping from the old IDL to the new one would solve the code portability issue. I don't consider to mapping old IDL to new IDL to be completely satisfactory: for example the old Allows_shared is mapped to ADAPTS/SHARED which has stronger semantics. Anyway, interoperability with "OTS + messaging changes" is not addressed at all by the latest base document or any other open issue. For example, a client with an OTS implementaion that implements "OTS + messaging" won't understand the new IOR components, and hence won't be able to talk properly to a server using an OTS that implements the latest OTF-RTF report -- unless this server also add the old components to its IORs. Conversely, is an OTS 1.2 client required to understand IORs that carry "OTS + messaging" components? Interoperability with 1.1 is specified (although it is right now a bit broken); but we have nothing about interoperability with "OTS + messaging changes". Regards, Bernard ----- Original Message ----- From: "Blake Biesecker" To: "Bernard Normier" Cc: Sent: Thursday, November 02, 2000 6:10 PM Subject: Re: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) > Bernard, > > To bring discussion to a finer point, I'd like to propose > this resolution to issue 3775: > > -------------------------------------------------------------- > Issue 3775: Policy split (OTSPolicy & InvocationPolicy) > > Click here for this issue's archive. > Source: IONA (Mr. Bernard Normier, bernard.normier@iona.com) > Nature: Uncategorized Issue > Severity: > Summary: Ram, Tom, all, > My main concern regarding the introduction of these two policies > is interoperability and source-code portability between > "OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're > working on. > > "OTS 1.1 + messaging updates" is a real adopted spec, not a working > draft. The (adopted) messaging spec refers to it. And I know at >least > one shipping implementation of this OTS revision. > > So far each new OTS revision (including "OTS 1.1 + messaging >updates") > has addressed interoperability with earlier revisions; I think > that it would not be wise to adopt a proposal that does not address > this concern. > > Also, the question asked by issue #3425 is "what shall I do when on > the client-side I get an IOR with no transaction policy component?". > Does the introduction of these new policies really help answering > this question? Maybe treating this as a separate issue would help > solve issue #3425. > Resolution: > The concern about "OTS 1.1 + messaging updates" interoperability >with > OTS 1.2 was addressed in the proposal for 3425 by deprecating TransactionPolicy > and related interfaces and const rather than removing them. A >mapping from > TransactionPolicyValues and the 1.2 policies is also provided. > > Issue 3991 was opened to address the concerns that 3425 didn't >address > regarding IORs without transaction policies. > > Since all the concerns raised in this issue have already been >addressed > or are being worked as part of other issues, this isssue is being >closed. > > Revised Text: > Actions taken: > August 18, 2000: received issue > -------------------------------------------------------------- > > I think it would be clearer if we resolve this issue in this > way and then open new issues on any particular "OTS 1.1 + messaging updates" > interoperability that you feel warrant further clarification. > > Blake > > On Thu, Nov 02, 2000 at 11:42:11AM -0800, Blake Biesecker wrote: > > What is insufficient about keeping the TransactionPolicy idl > > in for backward compatibility and mapping the old policies > > to the new? > > > > Are you interested in offering up a proposal to clarify > > the spec? > > > > Blake > > > > On Thu, Nov 02, 2000 at 11:40:37AM -0500, Bernard Normier wrote: > > > No, the resolutions to issues 3425 and 3991 did not address > > > interoperability with "OTS 1.1 + messaging updates". > > > > > > Regards, > > > > > > Bernard > > > ----- Original Message ----- > > > From: "Blake Biesecker" > > > To: > > > Cc: > > > Sent: Wednesday, November 01, 2000 8:44 PM > > > Subject: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) > > > > > > > > > > Bernard, > > > > > > > > I'm assuming that this issue is addressed by 3425 and 3991. > > > > Please let me know if you disagree. > > > > > > > > Blake > > > > > > > > On Wed, Aug 23, 2000 at 04:43:19PM -0400, Juergen Boldt wrote: > > > > > This is issue # 3775 "Bernard Normier" > > > > > > > > > > > Policy split (OTSPolicy & InvocationPolicy) > > > > > > > > > > Ram, Tom, all, > > > > > > > > > > My main concern regarding the introduction of these two >policies > > > > > is interoperability and source-code portability between > > > > > "OTS 1.1 + messaging updates" and the new OTS 1.2 revision >we're > > > > > working on. > > > > > > > > > > "OTS 1.1 + messaging updates" is a real adopted spec, not a working > > > > > draft. The (adopted) messaging spec refers to it. And I know >at least > > > > > one shipping implementation of this OTS revision. > > > > > > > > > > So far each new OTS revision (including "OTS 1.1 + messaging updates") > > > > > has addressed interoperability with earlier revisions; I >think > > > > > that it would not be wise to adopt a proposal that does not address > > > > > this concern. > > > > > > > > > > Also, the question asked by issue #3425 is "what shall I do >when on > > > > > the client-side I get an IOR with no transaction policy component?". > > > > > Does the introduction of these new policies really help >answering > > > > > this question? Maybe treating this as a separate issue would >help > > > > > solve issue #3425. > > > > > > > > > > > > > > > > > > > > >================================================================ > > > > > > > > > > Juergen Boldt > > > > > Senior Member of Technical Staff > > > > > > > > > > Object Management Group Tel. +1-781 444 0404 ext. 132 > > > > > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > > > > > Needham, MA 02494, USA Email: juergen@omg.org > > > > > > > > > > > > > > > > > > > > >================================================================ > > > > > > > > > > > Date: Thu, 2 Nov 2000 16:08:51 -0800 From: Blake Biesecker To: Bernard Normier Cc: ots-rtf@emerald.omg.org Subject: Re: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) Message-ID: <20001102160850.B23238@gemstone.com> References: <4.2.0.58.20000823164230.00a25ba0@emerald.omg.org> <20001101174400.G22453@gemstone.com> <00c601c044eb$a0e2b7f0$4985413f@boston.amer.iona.com> <20001102114210.E23041@gemstone.com> <20001102151059.K23041@gemstone.com> <031e01c04526$89e76150$4985413f@boston.amer.iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: <031e01c04526$89e76150$4985413f@boston.amer.iona.com>; from bernard.normier@iona.com on Thu, Nov 02, 2000 at 06:42:18PM -0500 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: bCVd9'mg!!68[!!JITd9 Yeah, you are right, these are problems. The way it is now, OTS implementations could be coded to understand and check for both "OTS + messaging changes" TransactionPolicy and 1.2 policies but it is not mandated. I personally don't have any interest in solving ths since "OTS + messaging changes" interperability with 1.2 isn't a concern to GemStone's customer base. So who is? Are you interested in coming up with a scheme to solve this issue and writing a proposal? (Is anyone else?) Blake On Thu, Nov 02, 2000 at 06:42:18PM -0500, Bernard Normier wrote: > Blake, > > Keeping the old IDL and defining a satisfactory mapping from > the old IDL to the new one would solve the code portability > issue. > > I don't consider to mapping old IDL to new IDL to be > completely satisfactory: > for example the old Allows_shared is mapped to ADAPTS/SHARED > which has stronger semantics. > > Anyway, interoperability with "OTS + messaging changes" is > not addressed at all by the latest base document or any > other open issue. > > For example, a client with an OTS implementaion that > implements "OTS + messaging" won't understand the new IOR > components, and hence won't be able to talk properly to > a server using an OTS that implements the latest OTF-RTF > report -- unless this server also add the old components > to its IORs. > > Conversely, is an OTS 1.2 client required to understand > IORs that carry "OTS + messaging" components? > > Interoperability with 1.1 is specified (although it is > right now a bit broken); but we have nothing about > interoperability with "OTS + messaging changes". > > Regards, > > Bernard > > ----- Original Message ----- > From: "Blake Biesecker" > To: "Bernard Normier" > Cc: > Sent: Thursday, November 02, 2000 6:10 PM > Subject: Re: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) > > > > Bernard, > > > > To bring discussion to a finer point, I'd like to propose > > this resolution to issue 3775: > > > > -------------------------------------------------------------- > > Issue 3775: Policy split (OTSPolicy & InvocationPolicy) > > > > Click here for this issue's archive. > > Source: IONA (Mr. Bernard Normier, bernard.normier@iona.com) > > Nature: Uncategorized Issue > > Severity: > > Summary: Ram, Tom, all, > > My main concern regarding the introduction of these two policies > > is interoperability and source-code portability between > > "OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're > > working on. > > > > "OTS 1.1 + messaging updates" is a real adopted spec, not a working > > draft. The (adopted) messaging spec refers to it. And I know at least > > one shipping implementation of this OTS revision. > > > > So far each new OTS revision (including "OTS 1.1 + messaging updates") > > has addressed interoperability with earlier revisions; I think > > that it would not be wise to adopt a proposal that does not address > > this concern. > > > > Also, the question asked by issue #3425 is "what shall I do when on > > the client-side I get an IOR with no transaction policy component?". > > Does the introduction of these new policies really help answering > > this question? Maybe treating this as a separate issue would help > > solve issue #3425. > > Resolution: > > The concern about "OTS 1.1 + messaging updates" interoperability with > > OTS 1.2 was addressed in the proposal for 3425 by deprecating > TransactionPolicy > > and related interfaces and const rather than removing them. A mapping from > > TransactionPolicyValues and the 1.2 policies is also provided. > > > > Issue 3991 was opened to address the concerns that 3425 didn't address > > regarding IORs without transaction policies. > > > > Since all the concerns raised in this issue have already been addressed > > or are being worked as part of other issues, this isssue is being closed. > > > > Revised Text: > > Actions taken: > > August 18, 2000: received issue > > -------------------------------------------------------------- > > > > I think it would be clearer if we resolve this issue in this > > way and then open new issues on any particular "OTS 1.1 + messaging > updates" > > interoperability that you feel warrant further clarification. > > > > Blake > > > > On Thu, Nov 02, 2000 at 11:42:11AM -0800, Blake Biesecker wrote: > > > What is insufficient about keeping the TransactionPolicy idl > > > in for backward compatibility and mapping the old policies > > > to the new? > > > > > > Are you interested in offering up a proposal to clarify > > > the spec? > > > > > > Blake > > > > > > On Thu, Nov 02, 2000 at 11:40:37AM -0500, Bernard Normier wrote: > > > > No, the resolutions to issues 3425 and 3991 did not address > > > > interoperability with "OTS 1.1 + messaging updates". > > > > > > > > Regards, > > > > > > > > Bernard > > > > ----- Original Message ----- > > > > From: "Blake Biesecker" > > > > To: > > > > Cc: > > > > Sent: Wednesday, November 01, 2000 8:44 PM > > > > Subject: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) > > > > > > > > > > > > > Bernard, > > > > > > > > > > I'm assuming that this issue is addressed by 3425 and 3991. > > > > > Please let me know if you disagree. > > > > > > > > > > Blake > > > > > > > > > > On Wed, Aug 23, 2000 at 04:43:19PM -0400, Juergen Boldt wrote: > > > > > > This is issue # 3775 "Bernard Normier" > > > > > > > > > > > > Policy split (OTSPolicy & InvocationPolicy) > > > > > > > > > > > > Ram, Tom, all, > > > > > > > > > > > > My main concern regarding the introduction of these two policies > > > > > > is interoperability and source-code portability between > > > > > > "OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're > > > > > > working on. > > > > > > > > > > > > "OTS 1.1 + messaging updates" is a real adopted spec, not a > working > > > > > > draft. The (adopted) messaging spec refers to it. And I know at > least > > > > > > one shipping implementation of this OTS revision. > > > > > > > > > > > > So far each new OTS revision (including "OTS 1.1 + messaging > updates") > > > > > > has addressed interoperability with earlier revisions; I think > > > > > > that it would not be wise to adopt a proposal that does not > address > > > > > > this concern. > > > > > > > > > > > > Also, the question asked by issue #3425 is "what shall I do when > on > > > > > > the client-side I get an IOR with no transaction policy > component?". > > > > > > Does the introduction of these new policies really help answering > > > > > > this question? Maybe treating this as a separate issue would help > > > > > > solve issue #3425. > > > > > > > > > > > > > > > > > > > > > > > > ================================================================ > > > > > > > > > > > > Juergen Boldt > > > > > > Senior Member of Technical Staff > > > > > > > > > > > > Object Management Group Tel. +1-781 444 0404 ext. 132 > > > > > > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > > > > > > Needham, MA 02494, USA Email: juergen@omg.org > > > > > > > > > > > > > > > > > > > > > > > > ================================================================ > > > > > > > > > > > > > > > > > From: "Bernard Normier" To: "Blake Biesecker" Cc: References: <4.2.0.58.20000823164230.00a25ba0@emerald.omg.org> <20001101174400.G22453@gemstone.com> <00c601c044eb$a0e2b7f0$4985413f@boston.amer.iona.com> <20001102114210.E23041@gemstone.com> <20001102151059.K23041@gemstone.com> <031e01c04526$89e76150$4985413f@boston.amer.iona.com> <20001102160850.B23238@gemstone.com> Subject: Re: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) Date: Mon, 6 Nov 2000 11:13:15 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text X-UIDL: 3$De9bbld96[+e9@8#e9 Hi Blake, Yes, we are interested in fixing these problems, and I'll try to come up with a proposal. In general, ensuring interoperability with previous revisions of the spec should not be an afterthought, and as chair of this RTF, I expect this would be your concern, even if GemStone did not implement every single revisions. Regards, Bernard ----- Original Message ----- From: "Blake Biesecker" To: "Bernard Normier" Cc: Sent: Thursday, November 02, 2000 7:08 PM Subject: Re: Issue 3775: Policy split (OTSPolicy & InvocationPolicy) > Yeah, you are right, these are problems. The way it is now, > OTS implementations could be coded to understand and check > for both "OTS + messaging changes" TransactionPolicy and > 1.2 policies but it is not mandated. > > I personally don't have any interest in solving ths since > "OTS + messaging changes" interperability with 1.2 isn't > a concern to GemStone's customer base. So who is? > > Are you interested in coming up with a scheme to solve > this issue and writing a proposal? (Is anyone else?) > > Blake > > On Thu, Nov 02, 2000 at 06:42:18PM -0500, Bernard Normier wrote: > > Blake, > > > > Keeping the old IDL and defining a satisfactory mapping from > > the old IDL to the new one would solve the code portability > > issue. > > > > I don't consider to mapping old IDL to new IDL to be > > completely satisfactory: > > for example the old Allows_shared is mapped to ADAPTS/SHARED > > which has stronger semantics. > > > > Anyway, interoperability with "OTS + messaging changes" is > > not addressed at all by the latest base document or any > > other open issue. > > > > For example, a client with an OTS implementaion that > > implements "OTS + messaging" won't understand the new IOR > > components, and hence won't be able to talk properly to > > a server using an OTS that implements the latest OTF-RTF > > report -- unless this server also add the old components > > to its IORs. > > > > Conversely, is an OTS 1.2 client required to understand > > IORs that carry "OTS + messaging" components? > > > > Interoperability with 1.1 is specified (although it is > > right now a bit broken); but we have nothing about > > interoperability with "OTS + messaging changes". > > > > Regards, > > > > Bernard > > > > ----- Original Message ----- > > From: "Blake Biesecker" > > To: "Bernard Normier" > > Cc: > > Sent: Thursday, November 02, 2000 6:10 PM > > Subject: Re: Issue 3775: Policy split (OTSPolicy & > InvocationPolicy) > > > > > > > Bernard, > > > > > > To bring discussion to a finer point, I'd like to propose > > > this resolution to issue 3775: > > > > > > -------------------------------------------------------------- > > > Issue 3775: Policy split (OTSPolicy & InvocationPolicy) > > > > > > Click here for this issue's archive. > > > Source: IONA (Mr. Bernard Normier, bernard.normier@iona.com) > > > Nature: Uncategorized Issue > > > Severity: > > > Summary: Ram, Tom, all, > > > My main concern regarding the introduction of these two policies > > > is interoperability and source-code portability between > > > "OTS 1.1 + messaging updates" and the new OTS 1.2 revision we're > > > working on. > > > > > > "OTS 1.1 + messaging updates" is a real adopted spec, not a > working > > > draft. The (adopted) messaging spec refers to it. And I know at > least > > > one shipping implementation of this OTS revision. > > > > > > So far each new OTS revision (including "OTS 1.1 + messaging > updates") > > > has addressed interoperability with earlier revisions; I think > > > that it would not be wise to adopt a proposal that does not > address > > > this concern. > > > > > > Also, the question asked by issue #3425 is "what shall I do when > on > > > the client-side I get an IOR with no transaction policy > component?". > > > Does the introduction of these new policies really help > answering > > > this question? Maybe treating this as a separate issue would > help > > > solve issue #3425. > > > Resolution: > > > The concern about "OTS 1.1 + messaging updates" interoperability > with > > > OTS 1.2 was addressed in the proposal for 3425 by deprecating > > TransactionPolicy > > > and related interfaces and const rather than removing them. A > mapping from > > > TransactionPolicyValues and the 1.2 policies is also provided. > > > > > > Issue 3991 was opened to address the concerns that 3425 didn't > address > > > regarding IORs without transaction policies. > > > > > > Since all the concerns raised in this issue have already been addressed > > > or are being worked as part of other issues, this isssue is > being closed. > > > > > > Revised Text: > > > Actions taken: > > > August 18, 2000: received issue > > > -------------------------------------------------------------- > > > > > > I think it would be clearer if we resolve this issue in this > > > way and then open new issues on any particular "OTS 1.1 + > messaging > > updates" > > > interoperability that you feel warrant further clarification. > > > > > > Blake > > > > > > On Thu, Nov 02, 2000 at 11:42:11AM -0800, Blake Biesecker wrote: > > > > What is insufficient about keeping the TransactionPolicy idl > > > > in for backward compatibility and mapping the old policies > > > > to the new? > > > > > > > > Are you interested in offering up a proposal to clarify > > > > the spec? > > > > > > > > Blake > > > > > > > > On Thu, Nov 02, 2000 at 11:40:37AM -0500, Bernard Normier > wrote: > > > > > No, the resolutions to issues 3425 and 3991 did not address > > > > > interoperability with "OTS 1.1 + messaging updates". > > > > > > > > > > Regards, > > > > > > > > > > Bernard > > > > > ----- Original Message ----- > > > > > From: "Blake Biesecker" > > > > > To: > > > > > Cc: > > > > > Sent: Wednesday, November 01, 2000 8:44 PM > > > > > Subject: Issue 3775: Policy split (OTSPolicy & > InvocationPolicy) > > > > > > > > > > > > > > > > Bernard, > > > > > > > > > > > > I'm assuming that this issue is addressed by 3425 and > 3991. > > > > > > Please let me know if you disagree. > > > > > > > > > > > > Blake > > > > > > > > > > > > On Wed, Aug 23, 2000 at 04:43:19PM -0400, Juergen Boldt > wrote: > > > > > > > This is issue # 3775 "Bernard Normier" > > > > > > > > > > > > > > Policy split (OTSPolicy & InvocationPolicy) > > > > > > > > > > > > > > Ram, Tom, all, > > > > > > > > > > > > > > My main concern regarding the introduction of these two policies > > > > > > > is interoperability and source-code portability between > > > > > > > "OTS 1.1 + messaging updates" and the new OTS 1.2 > revision we're > > > > > > > working on. > > > > > > > > > > > > > > "OTS 1.1 + messaging updates" is a real adopted spec, > not a > > working > > > > > > > draft. The (adopted) messaging spec refers to it. And I > know at > > least > > > > > > > one shipping implementation of this OTS revision. > > > > > > > > > > > > > > So far each new OTS revision (including "OTS 1.1 + > messaging > > updates") > > > > > > > has addressed interoperability with earlier revisions; I > think > > > > > > > that it would not be wise to adopt a proposal that does > not > > address > > > > > > > this concern. > > > > > > > > > > > > > > Also, the question asked by issue #3425 is "what shall I > do when > > on > > > > > > > the client-side I get an IOR with no transaction policy > > component?". > > > > > > > Does the introduction of these new policies really help answering > > > > > > > this question? Maybe treating this as a separate issue > would help > > > > > > > solve issue #3425. > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================ > > > > > > > > > > > > > > Juergen Boldt > > > > > > > Senior Member of Technical Staff > > > > > > > > > > > > > > Object Management Group Tel. +1-781 444 0404 ext. 132 > > > > > > > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > > > > > > > Needham, MA 02494, USA Email: juergen@omg.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > ================================================================ > > > > > > > > > > > > > > > > > > > > > > > >