Issue 3421: CosTSInteroperation not specified (ots-rtf) Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi@triodia.com) Nature: Uncategorized Issue Severity: Summary: Section 10.3.11 of ptc/99-10-07 shows the CosTSInteroperation module. However, that module does not appear in section 10.6, but should. In general, a sanity check of 10.6 against the rest of the spec seems advisable, so we can be sure that they actually match. Resolution: duplicate Revised Text: Actions taken: March 15, 2000: received issue February 27, 2001: closed issue Discussion: End of Annotations:===== Date: Wed, 15 Mar 2000 14:28:21 +1000 (EST) From: Michi Henning Reply-To: ots-rtf@omg.org To: ots-rtf@omg.org cc: issues@omg.org Subject: CosTSInteroperation not specified Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ~V@!!k!C!!;@Ud96Jnd9 Section 10.3.11 of ptc/99-10-07 shows the CosTSInteroperation module. However, that module does not appear in section 10.6, but should. In general, a sanity check of 10.6 against the rest of the spec seems advisable, so we can be sure that they actually match. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 26 Apr 2000 19:03:13 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: proposed resolutions for issues 3357, 3421, 3422, 3423 & 3559 Message-ID: <20000426190312.B8408@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: fgkd9/A9e9MY=e9!l7!! Below are the formal proposals that I plan to put up for a vote for these issues: Issue 3357: OTS-RTF issue: spelling/case of transaction policy values Issue 3421: CosTSInteroperation not specified Issue 3422: TranactionPolicyValue definition? Issue 3423: TransactionalPolicyComponent definition Issue 3559: Transaction policy IDL missing Please review and let me know if you see any problems or mistakes. Blake Proposed resolutions: ----------------------------- Issue 3357: OTS-RTF issue: spelling/case of transaction policy values Source: IONA (Mr. Bernard Normier, bernard.normier@iona.com) Nature: Uncategorized Issue Severity: Summary: The Messaging spec defined a strange case for transaction policy values. >From http://www.omg.org/pub/orbrev/drafts/10_trs11.pdf: const TransactionPolicyValue Allows_shared = 0; const TransactionPolicyValue Allows_none = 1; etc. I suggest to use instead the AB recommended case for IDL constants, i.e. all caps (see http://www.omg.org/docs/ab/98-06-03.pdf, 2.1.3): const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; etc. Resolution: The IDL for the TransactionPolicyValue constants will be changed to follow the AB recommended case for IDL constants, i.e. all capital letters. (See http://www.omg.org/docs/ab/98-06-03.pdf, section 2.1.3) So, for example, const TransactionPolicyValue Allows_shared = 0; const TransactionPolicyValue Allows_none = 1; etc. becomes: const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; etc. Revised Text: Change the IDL in section 10.2.4 from: enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, StatusCommitted, StatusRolledBack, StatusUnknown, StatusNoTransaction, StatusPreparing, StatusCommitting, StatusRollingBack }; enum Vote { VoteCommit, VoteRollback, VoteReadOnly }; typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue Allows_shared = 0; const TransactionPolicyValue Allows_none = 1; const TransactionPolicyValue Requires_shared = 2; const TransactionPolicyValue Allows_unshared = 3; const TransactionPolicyValue Allows_either = 4; const TransactionPolicyValue Requires_unshared = 5; const TransactionPolicyValue Requires_either = 6; to: enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, StatusCommitted, StatusRolledBack, StatusUnknown, StatusNoTransaction, StatusPreparing, StatusCommitting, StatusRollingBack }; enum Vote { VoteCommit, VoteRollback, VoteReadOnly }; typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; const TransactionPolicyValue REQUIRES_SHARED = 2; const TransactionPolicyValue ALLOWS_UNSHARED = 3; const TransactionPolicyValue ALLOWS_EITHER = 4; const TransactionPolicyValue REQUIRES_UNSHARED = 5; const TransactionPolicyValue REQUIRES_EITHER = 6; Sections 10.3.10 and 10.6 will be changed in the same way. Actions taken: February 23, 2000: received issue ----------------------------- ----------------------------- Issue 3421: CosTSInteroperation not specified (ots-rtf) Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Section 10.3.11 of ptc/99-10-07 shows the CosTSInteroperation module. However, that module does not appear in section 10.6, but should. In general, a sanity check of 10.6 against the rest of the spec seems advisable, so we can be sure that they actually match. Resolution: Change the IDL at the end section 10.3.10 from: const CORBA::PolicyType TransactionPolicyType = 46; interface TransactionPolicy : CORBA::Policy { readonly attribute TransactionPolicyValue tpv; }; to: typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; const TransactionPolicyValue REQUIRES_SHARED = 2; const TransactionPolicyValue ALLOWS_UNSHARED = 3; const TransactionPolicyValue ALLOWS_EITHER = 4; const TransactionPolicyValue REQUIRES_UNSHARED = 5; const TransactionPolicyValue REQUIRES_EITHER = 6; const CORBA::PolicyType TransactionPolicyType = 46; interface TransactionPolicy : CORBA::Policy { readonly attribute TransactionPolicyValue tpv; }; In section 10.6 add this IDL: typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; const TransactionPolicyValue REQUIRES_SHARED = 2; const TransactionPolicyValue ALLOWS_UNSHARED = 3; const TransactionPolicyValue ALLOWS_EITHER = 4; const TransactionPolicyValue REQUIRES_UNSHARED = 5; const TransactionPolicyValue REQUIRES_EITHER = 6; const CORBA::PolicyType TransactionPolicyType = 46; interface TransactionPolicy : CORBA::Policy { readonly attribute TransactionPolicyValue tpv; }; (Some working drafts of the OTS spec already contain part of this idl in section 10.6, but this just ensures that it is complete and has the correct capitalization in the final version.) Add a section 10.6.2 called "The CosTSInteroperation Module" which contains this IDL: module CosTSInteroperation { const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 }; Revised Text: Actions taken: March 15, 2000: received issue ----------------------------- ----------------------------- Issue 3422: TranactionPolicyValue definition? (ots-rtf) Click here for this issue's archive. Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Page 35 of ptc/99-10-07 shows the TransactionPolicy interface. That interface contains an attribute of type TransactionPolicyValue, but that type is not defined anywhere. Resolution: fixed with changes made by resolution for issue 3421 Revised Text: Actions taken: March 15, 2000: received issue Issue 3423: TransactionalPolicyComponent definition (ots-rtf) Click here for this issue's archive. Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Page 36 of ptc/99-10-07 defines TransactionPolicyComponent. That type is a struct with a single member. It doesn't make sense to have a structure with only one member, so it would seem advisable to drop the structure. Resolution: Change the CosTSInteroperation IDL module from: module CosTSInteroperation { const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 struct TransactionPolicyComponent { TransactionPolicyValue tpv; }; }; to: module CosTSInteroperation { const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 }; Revised Text: Change IDL in section 10.3.11 from: module CosTSInteroperation { const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 struct TransactionPolicyComponent { TransactionPolicyValue tpv; }; }; to: module CosTSInteroperation { const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 }; Actions taken: March 15, 2000: received issue ----------------------------- ----------------------------- Issue 3559: Transaction policy IDL missing (ots-rtf) Click here for this issue's archive. Source: Hewlett-Packard (Dr. Jishnu Mukerji, jis@fpk.hp.com) Nature: Uncategorized Issue Severity: Summary: The IDL for TransactionPolicy and TransactionPolicyComponent needs to be include in the CosTransaction module. As far as I can tell that is where these belong, since they certainly don't seem to belong anywhere else. They are missing in ptc/99-10-07. I don't know if this has been fixed in a later draft. Resolution: fixed with changes made in resolution for issue 3421 Revised Text: Actions taken: April 13, 2000: received issue ----------------------------- Reply-To: From: "Martin S Tonge" To: Subject: RE: proposed resolutions for issues 3357, 3421, 3422, 3423 & 3559 Date: Thu, 27 Apr 2000 11:31:49 +0100 Message-ID: <000101bfb033$cd5120d0$6210a8c0@mart539469.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20000426190312.B8408@gemstone.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: F&,!!&9Me9Q&/e9K69!! As an observer I have a small observation to make regarding the declaration of Policy Values. In the POA specification policy values are defined as enumerated types as opposed to Policy Types which are defined as const declarations. From a pragmatic point of view the end result is the same, but for consistency shouldn't a TransactionPolicy be an enumerated type? To be fair, I don't know how other IDL specs treat Policy Values. Hence -> typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; const TransactionPolicyValue REQUIRES_SHARED = 2; const TransactionPolicyValue ALLOWS_UNSHARED = 3; const TransactionPolicyValue ALLOWS_EITHER = 4; const TransactionPolicyValue REQUIRES_UNSHARED = 5; const TransactionPolicyValue REQUIRES_EITHER = 6; is really enum TransactionPolicyValue { ALLOWS_SHARED, ALLOWS_NONE, REQUIRES_SHARED, ALLOWS_UNSHARED, ALLOWS_EITHER, REQUIRES_UNSHARED, REQUIRES_EITHER } Regards Martin (Martin Tonge/ PeerLogic Ltd) -----Original Message----- From: Blake Biesecker [mailto:blakeb@gemstone.com] Sent: Thursday, April 27, 2000 3:03 AM To: ots-rtf@omg.org Subject: proposed resolutions for issues 3357, 3421, 3422, 3423 & 3559 Below are the formal proposals that I plan to put up for a vote for these issues: Issue 3357: OTS-RTF issue: spelling/case of transaction policy values Issue 3421: CosTSInteroperation not specified Issue 3422: TranactionPolicyValue definition? Issue 3423: TransactionalPolicyComponent definition Issue 3559: Transaction policy IDL missing Please review and let me know if you see any problems or mistakes. Blake Proposed resolutions: ----------------------------- Issue 3357: OTS-RTF issue: spelling/case of transaction policy values Source: IONA (Mr. Bernard Normier, bernard.normier@iona.com) Nature: Uncategorized Issue Severity: Summary: The Messaging spec defined a strange case for transaction policy values. >From http://www.omg.org/pub/orbrev/drafts/10_trs11.pdf: const TransactionPolicyValue Allows_shared = 0; const TransactionPolicyValue Allows_none = 1; etc. I suggest to use instead the AB recommended case for IDL constants, i.e. all caps (see http://www.omg.org/docs/ab/98-06-03.pdf, 2.1.3): const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; etc. Resolution: The IDL for the TransactionPolicyValue constants will be changed to follow the AB recommended case for IDL constants, i.e. all capital letters. (See http://www.omg.org/docs/ab/98-06-03.pdf, section 2.1.3) So, for example, const TransactionPolicyValue Allows_shared = 0; const TransactionPolicyValue Allows_none = 1; etc. becomes: const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; etc. Revised Text: Change the IDL in section 10.2.4 from: enum Status StatusActive, StatusMarkedRollback, StatusPrepared, StatusCommitted, StatusRolledBack, StatusUnknown, StatusNoTransaction, StatusPreparing, StatusCommitting, StatusRollingBack }; enum Vote VoteCommit, VoteRollback, VoteReadOnly }; typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue Allows_shared = 0; const TransactionPolicyValue Allows_none = 1; const TransactionPolicyValue Requires_shared = 2; const TransactionPolicyValue Allows_unshared = 3; const TransactionPolicyValue Allows_either = 4; const TransactionPolicyValue Requires_unshared = 5; const TransactionPolicyValue Requires_either = 6; to: enum Status StatusActive, StatusMarkedRollback, StatusPrepared, StatusCommitted, StatusRolledBack, StatusUnknown, StatusNoTransaction, StatusPreparing, StatusCommitting, StatusRollingBack }; enum Vote VoteCommit, VoteRollback, VoteReadOnly }; typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; const TransactionPolicyValue REQUIRES_SHARED = 2; const TransactionPolicyValue ALLOWS_UNSHARED = 3; const TransactionPolicyValue ALLOWS_EITHER = 4; const TransactionPolicyValue REQUIRES_UNSHARED = 5; const TransactionPolicyValue REQUIRES_EITHER = 6; Sections 10.3.10 and 10.6 will be changed in the same way. Actions taken: February 23, 2000: received issue ----------------------------- ----------------------------- Issue 3421: CosTSInteroperation not specified (ots-rtf) Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Section 10.3.11 of ptc/99-10-07 shows the CosTSInteroperation module. However, that module does not appear in section 10.6, but should. In general, a sanity check of 10.6 against the rest of the spec seems advisable, so we can be sure that they actually match. Resolution: Change the IDL at the end section 10.3.10 from: const CORBA::PolicyType TransactionPolicyType = 46; interface TransactionPolicy : CORBA::Policy readonly attribute TransactionPolicyValue tpv; }; to: typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; const TransactionPolicyValue REQUIRES_SHARED = 2; const TransactionPolicyValue ALLOWS_UNSHARED = 3; const TransactionPolicyValue ALLOWS_EITHER = 4; const TransactionPolicyValue REQUIRES_UNSHARED = 5; const TransactionPolicyValue REQUIRES_EITHER = 6; const CORBA::PolicyType TransactionPolicyType = 46; interface TransactionPolicy : CORBA::Policy readonly attribute TransactionPolicyValue tpv; }; In section 10.6 add this IDL: typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; const TransactionPolicyValue REQUIRES_SHARED = 2; const TransactionPolicyValue ALLOWS_UNSHARED = 3; const TransactionPolicyValue ALLOWS_EITHER = 4; const TransactionPolicyValue REQUIRES_UNSHARED = 5; const TransactionPolicyValue REQUIRES_EITHER = 6; const CORBA::PolicyType TransactionPolicyType = 46; interface TransactionPolicy : CORBA::Policy readonly attribute TransactionPolicyValue tpv; }; (Some working drafts of the OTS spec already contain part of this idl in section 10.6, but this just ensures that it is complete and has the correct capitalization in the final version.) Add a section 10.6.2 called "The CosTSInteroperation Module" which contains this IDL: module CosTSInteroperation const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 }; Revised Text: Actions taken: March 15, 2000: received issue ----------------------------- ----------------------------- Issue 3422: TranactionPolicyValue definition? (ots-rtf) Click here for this issue's archive. Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Page 35 of ptc/99-10-07 shows the TransactionPolicy interface. That interface contains an attribute of type TransactionPolicyValue, but that type is not defined anywhere. Resolution: fixed with changes made by resolution for issue 3421 Revised Text: Actions taken: March 15, 2000: received issue Issue 3423: TransactionalPolicyComponent definition (ots-rtf) Click here for this issue's archive. Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Page 36 of ptc/99-10-07 defines TransactionPolicyComponent. That type is a struct with a single member. It doesn't make sense to have a structure with only one member, so it would seem advisable to drop the structure. Resolution: Change the CosTSInteroperation IDL module from: module CosTSInteroperation const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 struct TransactionPolicyComponent TransactionPolicyValue tpv; }; }; to: module CosTSInteroperation const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 }; Revised Text: Change IDL in section 10.3.11 from: module CosTSInteroperation const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 struct TransactionPolicyComponent TransactionPolicyValue tpv; }; }; to: module CosTSInteroperation const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 }; Actions taken: March 15, 2000: received issue ----------------------------- ----------------------------- Issue 3559: Transaction policy IDL missing (ots-rtf) Click here for this issue's archive. Source: Hewlett-Packard (Dr. Jishnu Mukerji, jis@fpk.hp.com) Nature: Uncategorized Issue Severity: Summary: The IDL for TransactionPolicy and TransactionPolicyComponent needs to be include in the CosTransaction module. As far as I can tell that is where these belong, since they certainly don't seem to belong anywhere else. They are missing in ptc/99-10-07. I don't know if this has been fixed in a later draft. Resolution: fixed with changes made in resolution for issue 3421 Revised Text: Actions taken: April 13, 2000: received issue ----------------------------- Date: Thu, 27 Apr 2000 22:43:38 +1000 (EST) From: Michi Henning To: Martin S Tonge cc: ots-rtf@omg.org Subject: RE: proposed resolutions for issues 3357, 3421, 3422, 3423 & 3559 In-Reply-To: <000101bfb033$cd5120d0$6210a8c0@mart539469.uk.peerlogic.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: #$jd91X$e9M!#"!D[k!! On Thu, 27 Apr 2000, Martin S Tonge wrote: > As an observer I have a small observation to make regarding the declaration > of Policy Values. In the POA specification policy values are defined as > enumerated types as opposed to Policy Types which are defined as const > declarations. From a pragmatic point of view the end result is the same, but > for consistency shouldn't a TransactionPolicy be an enumerated type? To be > fair, I don't know how other IDL specs treat Policy Values. Some time ago, we decided that enumerated values are politically incorrect :-) The reason is that, once an enumerated type is written, it cannot be changed without causing all sorts of versioning problems. On the other hand, adding another constant definition causes no problems. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 27 Apr 2000 13:23:29 -0700 To: Blake Biesecker , ots-rtf@omg.org From: Edward Cobb Subject: Re: proposed resolutions for issues 3357, 3421, 3422, 3423 & 3559 In-Reply-To: <20000426190312.B8408@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: X1De9h-cd9JBBelow are the formal proposals that I plan to put up for a >vote for these issues: > >Issue 3357: OTS-RTF issue: spelling/case of transaction policy values >Issue 3421: CosTSInteroperation not specified >Issue 3422: TranactionPolicyValue definition? >Issue 3423: TransactionalPolicyComponent definition >Issue 3559: Transaction policy IDL missing > >Please review and let me know if you see any problems or mistakes. > >Blake > > >Proposed resolutions: > >----------------------------- >Issue 3357: OTS-RTF issue: spelling/case of transaction policy values >Source: IONA (Mr. Bernard Normier, bernard.normier@iona.com) >Nature: Uncategorized Issue >Severity: >Summary: The Messaging spec defined a strange case for transaction >policy values. > >From http://www.omg.org/pub/orbrev/drafts/10_trs11.pdf: > >const TransactionPolicyValue Allows_shared = 0; >const TransactionPolicyValue Allows_none = 1; >etc. > >I suggest to use instead the AB recommended case for IDL constants, i.e. >all caps (see http://www.omg.org/docs/ab/98-06-03.pdf, 2.1.3): > >const TransactionPolicyValue ALLOWS_SHARED = 0; >const TransactionPolicyValue ALLOWS_NONE = 1; >etc. > >Resolution: > >The IDL for the TransactionPolicyValue constants will be >changed to follow the AB recommended case for IDL constants, >i.e. all capital letters. (See http://www.omg.org/docs/ab/98-06-03.pdf, >section 2.1.3) > >So, for example, > >const TransactionPolicyValue Allows_shared = 0; >const TransactionPolicyValue Allows_none = 1; >etc. > >becomes: > >const TransactionPolicyValue ALLOWS_SHARED = 0; >const TransactionPolicyValue ALLOWS_NONE = 1; >etc. > >Revised Text: > >Change the IDL in section 10.2.4 from: > >enum Status { > StatusActive, > StatusMarkedRollback, > StatusPrepared, > StatusCommitted, > StatusRolledBack, > StatusUnknown, > StatusNoTransaction, > StatusPreparing, > StatusCommitting, > StatusRollingBack >}; > >enum Vote { > VoteCommit, > VoteRollback, > VoteReadOnly >}; > >typedef unsigned short TransactionPolicyValue; > >const TransactionPolicyValue Allows_shared = 0; >const TransactionPolicyValue Allows_none = 1; >const TransactionPolicyValue Requires_shared = 2; >const TransactionPolicyValue Allows_unshared = 3; >const TransactionPolicyValue Allows_either = 4; >const TransactionPolicyValue Requires_unshared = 5; >const TransactionPolicyValue Requires_either = 6; > >to: > >enum Status { > StatusActive, > StatusMarkedRollback, > StatusPrepared, > StatusCommitted, > StatusRolledBack, > StatusUnknown, > StatusNoTransaction, > StatusPreparing, > StatusCommitting, > StatusRollingBack >}; > >enum Vote { > VoteCommit, > VoteRollback, > VoteReadOnly >}; > >typedef unsigned short TransactionPolicyValue; > >const TransactionPolicyValue ALLOWS_SHARED = 0; >const TransactionPolicyValue ALLOWS_NONE = 1; >const TransactionPolicyValue REQUIRES_SHARED = 2; >const TransactionPolicyValue ALLOWS_UNSHARED = 3; >const TransactionPolicyValue ALLOWS_EITHER = 4; >const TransactionPolicyValue REQUIRES_UNSHARED = 5; >const TransactionPolicyValue REQUIRES_EITHER = 6; > >Sections 10.3.10 and 10.6 will be changed in >the same way. > >Actions taken: >February 23, 2000: received issue >----------------------------- > >----------------------------- >Issue 3421: CosTSInteroperation not specified (ots-rtf) > >Source: Object Oriented Concepts (Mr. Michi Henning, >michi@ooc.com.au) >Nature: Uncategorized Issue >Severity: >Summary: Section 10.3.11 of ptc/99-10-07 shows the >CosTSInteroperation >module. However, that module does not appear in section 10.6, but >should. >In general, a sanity check of 10.6 against the rest of the spec seems >advisable, so we can be sure that they actually match. > >Resolution: > >Change the IDL at the end section 10.3.10 from: > >const CORBA::PolicyType TransactionPolicyType = 46; > >interface TransactionPolicy : CORBA::Policy { > readonly attribute TransactionPolicyValue tpv; >}; > >to: > >typedef unsigned short TransactionPolicyValue; > >const TransactionPolicyValue ALLOWS_SHARED = 0; >const TransactionPolicyValue ALLOWS_NONE = 1; >const TransactionPolicyValue REQUIRES_SHARED = 2; >const TransactionPolicyValue ALLOWS_UNSHARED = 3; >const TransactionPolicyValue ALLOWS_EITHER = 4; >const TransactionPolicyValue REQUIRES_UNSHARED = 5; >const TransactionPolicyValue REQUIRES_EITHER = 6; > >const CORBA::PolicyType TransactionPolicyType = 46; > >interface TransactionPolicy : CORBA::Policy { > readonly attribute TransactionPolicyValue tpv; >}; > >In section 10.6 add this IDL: > >typedef unsigned short TransactionPolicyValue; > >const TransactionPolicyValue ALLOWS_SHARED = 0; >const TransactionPolicyValue ALLOWS_NONE = 1; >const TransactionPolicyValue REQUIRES_SHARED = 2; >const TransactionPolicyValue ALLOWS_UNSHARED = 3; >const TransactionPolicyValue ALLOWS_EITHER = 4; >const TransactionPolicyValue REQUIRES_UNSHARED = 5; >const TransactionPolicyValue REQUIRES_EITHER = 6; > >const CORBA::PolicyType TransactionPolicyType = 46; > >interface TransactionPolicy : CORBA::Policy { > readonly attribute TransactionPolicyValue tpv; >}; > >(Some working drafts of the OTS spec already contain >part of this idl in section 10.6, but this just ensures >that it is complete and has the correct capitalization >in the final version.) > >Add a section 10.6.2 called "The CosTSInteroperation Module" >which contains this IDL: > >module CosTSInteroperation { > const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 >}; > >Revised Text: >Actions taken: >March 15, 2000: received issue >----------------------------- > >----------------------------- >Issue 3422: TranactionPolicyValue definition? (ots-rtf) > >Click here for this issue's archive. >Source: Object Oriented Concepts (Mr. Michi Henning, >michi@ooc.com.au) >Nature: Uncategorized Issue >Severity: >Summary: Page 35 of ptc/99-10-07 shows the TransactionPolicy >interface. >That interface contains an attribute of type TransactionPolicyValue, >but >that type is not defined anywhere. >Resolution: fixed with changes made by resolution for issue 3421 >Revised Text: >Actions taken: >March 15, 2000: received issue > > >Issue 3423: TransactionalPolicyComponent definition (ots-rtf) > >Click here for this issue's archive. >Source: Object Oriented Concepts (Mr. Michi Henning, >michi@ooc.com.au) >Nature: Uncategorized Issue >Severity: >Summary: Page 36 of ptc/99-10-07 defines TransactionPolicyComponent. >That type is a struct with a single member. It doesn't make sense to >have a structure with only one member, so it would seem advisable to >drop the structure. > >Resolution: > >Change the CosTSInteroperation IDL module from: > >module CosTSInteroperation { > const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 > struct TransactionPolicyComponent { > TransactionPolicyValue tpv; > }; >}; > >to: > >module CosTSInteroperation { > const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 >}; > >Revised Text: > >Change IDL in section 10.3.11 from: > >module CosTSInteroperation { > const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 > struct TransactionPolicyComponent { > TransactionPolicyValue tpv; > }; >}; > >to: > >module CosTSInteroperation { > const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 >}; > >Actions taken: >March 15, 2000: received issue >----------------------------- > >----------------------------- >Issue 3559: Transaction policy IDL missing (ots-rtf) > >Click here for this issue's archive. >Source: Hewlett-Packard (Dr. Jishnu Mukerji, jis@fpk.hp.com) >Nature: Uncategorized Issue >Severity: >Summary: The IDL for TransactionPolicy and TransactionPolicyComponent >needs to be include in the CosTransaction module. As far as I can >tell >that is where these belong, since they certainly don't seem to belong >anywhere else. They are missing in ptc/99-10-07. I don't know if this >has been fixed in a later draft. >Resolution: fixed with changes made in resolution for issue 3421 >Revised Text: >Actions taken: >April 13, 2000: received issue >----------------------------- > > > > ************************************************************** Ed Cobb, Director, 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: Thu, 27 Apr 2000 14:44:44 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: [ed.cobb@bea.com: Re: proposed resolutions for issues 3357, 3421, 3422, 3423 & 3559] Message-ID: <20000427144443.H18983@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: ?_`d9,~_!!n!Fe9?#?!! I agree with Ed. Does anyone have objections to me changing the proposals for these issues to roll the CosTSInteroperation module into Cos Transactions? Blake ----- Forwarded message from Edward Cobb ----- X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 27 Apr 2000 13:23:29 -0700 To: Blake Biesecker , ots-rtf@omg.org From: Edward Cobb Subject: Re: proposed resolutions for issues 3357, 3421, 3422, 3423 & 3559 In-Reply-To: <20000426190312.B8408@gemstone.com> Blake, the only thing I noticed is that you are proposing to include a separate module for the POA policy rather than move that definition into the CosTransaction module. I raised this as an issue to be discussed and Jishnu, I believe, suggested that we fold it into Cos Transactions and get rid of the CosTSInteroperation module. I can live with either solution, but I don't know how everyone else feels. At 07:03 PM 4/26/00 -0700, Blake Biesecker wrote: >Below are the formal proposals that I plan to put up for a >vote for these issues: > >Issue 3357: OTS-RTF issue: spelling/case of transaction policy values >Issue 3421: CosTSInteroperation not specified >Issue 3422: TranactionPolicyValue definition? >Issue 3423: TransactionalPolicyComponent definition >Issue 3559: Transaction policy IDL missing > >Please review and let me know if you see any problems or mistakes. > >Blake > > >Proposed resolutions: > >----------------------------- >Issue 3357: OTS-RTF issue: spelling/case of transaction policy values >Source: IONA (Mr. Bernard Normier, bernard.normier@iona.com) >Nature: Uncategorized Issue >Severity: >Summary: The Messaging spec defined a strange case for transaction >policy values. > >From http://www.omg.org/pub/orbrev/drafts/10_trs11.pdf: > >const TransactionPolicyValue Allows_shared = 0; >const TransactionPolicyValue Allows_none = 1; >etc. > >I suggest to use instead the AB recommended case for IDL constants, i.e. >all caps (see http://www.omg.org/docs/ab/98-06-03.pdf, 2.1.3): > >const TransactionPolicyValue ALLOWS_SHARED = 0; >const TransactionPolicyValue ALLOWS_NONE = 1; >etc. > >Resolution: > >The IDL for the TransactionPolicyValue constants will be >changed to follow the AB recommended case for IDL constants, >i.e. all capital letters. (See http://www.omg.org/docs/ab/98-06-03.pdf, >section 2.1.3) > >So, for example, > >const TransactionPolicyValue Allows_shared = 0; >const TransactionPolicyValue Allows_none = 1; >etc. > >becomes: > >const TransactionPolicyValue ALLOWS_SHARED = 0; >const TransactionPolicyValue ALLOWS_NONE = 1; >etc. > >Revised Text: > >Change the IDL in section 10.2.4 from: > >enum Status { > StatusActive, > StatusMarkedRollback, > StatusPrepared, > StatusCommitted, > StatusRolledBack, > StatusUnknown, > StatusNoTransaction, > StatusPreparing, > StatusCommitting, > StatusRollingBack >}; > >enum Vote { > VoteCommit, > VoteRollback, > VoteReadOnly >}; > >typedef unsigned short TransactionPolicyValue; > >const TransactionPolicyValue Allows_shared = 0; >const TransactionPolicyValue Allows_none = 1; >const TransactionPolicyValue Requires_shared = 2; >const TransactionPolicyValue Allows_unshared = 3; >const TransactionPolicyValue Allows_either = 4; >const TransactionPolicyValue Requires_unshared = 5; >const TransactionPolicyValue Requires_either = 6; > >to: > >enum Status { > StatusActive, > StatusMarkedRollback, > StatusPrepared, > StatusCommitted, > StatusRolledBack, > StatusUnknown, > StatusNoTransaction, > StatusPreparing, > StatusCommitting, > StatusRollingBack >}; > >enum Vote { > VoteCommit, > VoteRollback, > VoteReadOnly >}; > >typedef unsigned short TransactionPolicyValue; > >const TransactionPolicyValue ALLOWS_SHARED = 0; >const TransactionPolicyValue ALLOWS_NONE = 1; >const TransactionPolicyValue REQUIRES_SHARED = 2; >const TransactionPolicyValue ALLOWS_UNSHARED = 3; >const TransactionPolicyValue ALLOWS_EITHER = 4; >const TransactionPolicyValue REQUIRES_UNSHARED = 5; >const TransactionPolicyValue REQUIRES_EITHER = 6; > >Sections 10.3.10 and 10.6 will be changed in >the same way. > >Actions taken: >February 23, 2000: received issue >----------------------------- > >----------------------------- >Issue 3421: CosTSInteroperation not specified (ots-rtf) > >Source: Object Oriented Concepts (Mr. Michi Henning, >michi@ooc.com.au) >Nature: Uncategorized Issue >Severity: >Summary: Section 10.3.11 of ptc/99-10-07 shows the >CosTSInteroperation >module. However, that module does not appear in section 10.6, but >should. >In general, a sanity check of 10.6 against the rest of the spec seems >advisable, so we can be sure that they actually match. > >Resolution: > >Change the IDL at the end section 10.3.10 from: > >const CORBA::PolicyType TransactionPolicyType = 46; > >interface TransactionPolicy : CORBA::Policy { > readonly attribute TransactionPolicyValue tpv; >}; > >to: > >typedef unsigned short TransactionPolicyValue; > >const TransactionPolicyValue ALLOWS_SHARED = 0; >const TransactionPolicyValue ALLOWS_NONE = 1; >const TransactionPolicyValue REQUIRES_SHARED = 2; >const TransactionPolicyValue ALLOWS_UNSHARED = 3; >const TransactionPolicyValue ALLOWS_EITHER = 4; >const TransactionPolicyValue REQUIRES_UNSHARED = 5; >const TransactionPolicyValue REQUIRES_EITHER = 6; > >const CORBA::PolicyType TransactionPolicyType = 46; > >interface TransactionPolicy : CORBA::Policy { > readonly attribute TransactionPolicyValue tpv; >}; > >In section 10.6 add this IDL: > >typedef unsigned short TransactionPolicyValue; > >const TransactionPolicyValue ALLOWS_SHARED = 0; >const TransactionPolicyValue ALLOWS_NONE = 1; >const TransactionPolicyValue REQUIRES_SHARED = 2; >const TransactionPolicyValue ALLOWS_UNSHARED = 3; >const TransactionPolicyValue ALLOWS_EITHER = 4; >const TransactionPolicyValue REQUIRES_UNSHARED = 5; >const TransactionPolicyValue REQUIRES_EITHER = 6; > >const CORBA::PolicyType TransactionPolicyType = 46; > >interface TransactionPolicy : CORBA::Policy { > readonly attribute TransactionPolicyValue tpv; >}; > >(Some working drafts of the OTS spec already contain >part of this idl in section 10.6, but this just ensures >that it is complete and has the correct capitalization >in the final version.) > >Add a section 10.6.2 called "The CosTSInteroperation Module" >which contains this IDL: > >module CosTSInteroperation { > const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 >}; > >Revised Text: >Actions taken: >March 15, 2000: received issue >----------------------------- > >----------------------------- >Issue 3422: TranactionPolicyValue definition? (ots-rtf) > >Click here for this issue's archive. >Source: Object Oriented Concepts (Mr. Michi Henning, >michi@ooc.com.au) >Nature: Uncategorized Issue >Severity: >Summary: Page 35 of ptc/99-10-07 shows the TransactionPolicy >interface. >That interface contains an attribute of type TransactionPolicyValue, >but >that type is not defined anywhere. >Resolution: fixed with changes made by resolution for issue 3421 >Revised Text: >Actions taken: >March 15, 2000: received issue > > >Issue 3423: TransactionalPolicyComponent definition (ots-rtf) > >Click here for this issue's archive. >Source: Object Oriented Concepts (Mr. Michi Henning, >michi@ooc.com.au) >Nature: Uncategorized Issue >Severity: >Summary: Page 36 of ptc/99-10-07 defines TransactionPolicyComponent. >That type is a struct with a single member. It doesn't make sense to >have a structure with only one member, so it would seem advisable to >drop the structure. > >Resolution: > >Change the CosTSInteroperation IDL module from: > >module CosTSInteroperation { > const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 > struct TransactionPolicyComponent { > TransactionPolicyValue tpv; > }; >}; > >to: > >module CosTSInteroperation { > const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 >}; > >Revised Text: > >Change IDL in section 10.3.11 from: > >module CosTSInteroperation { > const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 > struct TransactionPolicyComponent { > TransactionPolicyValue tpv; > }; >}; > >to: > >module CosTSInteroperation { > const IOP::ComponentId TAG_TRANSACTION_POLICY = 26 >}; > >Actions taken: >March 15, 2000: received issue >----------------------------- > >----------------------------- >Issue 3559: Transaction policy IDL missing (ots-rtf) > >Click here for this issue's archive. >Source: Hewlett-Packard (Dr. Jishnu Mukerji, jis@fpk.hp.com) >Nature: Uncategorized Issue >Severity: >Summary: The IDL for TransactionPolicy and TransactionPolicyComponent >needs to be include in the CosTransaction module. As far as I can >tell >that is where these belong, since they certainly don't seem to belong >anywhere else. They are missing in ptc/99-10-07. I don't know if this >has been fixed in a later draft. >Resolution: fixed with changes made in resolution for issue 3421 >Revised Text: >Actions taken: >April 13, 2000: received issue >----------------------------- > > > > ************************************************************** Ed Cobb, Director, 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 ************************************************************** ----- End forwarded message ----- Date: Sat, 29 Apr 2000 09:21:12 +1000 (EST) From: Michi Henning To: Edward Cobb cc: Blake Biesecker , ots-rtf@omg.org Subject: Re: proposed resolutions for issues 3357, 3421, 3422, 3423 & 3559 In-Reply-To: <3.0.5.32.20000427132329.00c553c0@svlhome2.beasys.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: C!`!!Y>N!!Ci,!!)+"!! On Thu, 27 Apr 2000, Edward Cobb wrote: > Blake, the only thing I noticed is that you are proposing to include a > separate module for the POA policy rather than move that definition into > the CosTransaction module. I raised this as an issue to be discussed and > Jishnu, I believe, suggested that we fold it into Cos Transactions and get > rid of the CosTSInteroperation module. I can live with either solution, but > I don't know how everyone else feels. I like Jishnu's suggestion. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Mon, 1 May 2000 13:19:35 -0700 From: Blake Biesecker To: ots-rtf@omg.org Subject: [blakeb@gemstone.com: proposed resolutions for issues 3357, 3421, 3422, 3423 & 3559] Message-ID: <20000501131935.A4899@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: XB=e9ipEe9>nkd9F[C!! I revised the proposals below to roll TAG_TRANSACTION_POLICY into the CosTransactions module. Blake --------------------------------------------------------------------- Below are the formal proposals that I plan to put up for a vote for these issues: Issue 3357: OTS-RTF issue: spelling/case of transaction policy values Issue 3421: CosTSInteroperation not specified Issue 3422: TranactionPolicyValue definition? Issue 3423: TransactionalPolicyComponent definition Issue 3559: Transaction policy IDL missing Please review and let me know if you see any problems or mistakes. Blake Proposed resolutions: ----------------------------- Issue 3357: OTS-RTF issue: spelling/case of transaction policy values Source: IONA (Mr. Bernard Normier, bernard.normier@iona.com) Nature: Uncategorized Issue Severity: Summary: The Messaging spec defined a strange case for transaction policy values. >From http://www.omg.org/pub/orbrev/drafts/10_trs11.pdf: const TransactionPolicyValue Allows_shared = 0; const TransactionPolicyValue Allows_none = 1; etc. I suggest to use instead the AB recommended case for IDL constants, i.e. all caps (see http://www.omg.org/docs/ab/98-06-03.pdf, 2.1.3): const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; etc. Resolution: The IDL for the TransactionPolicyValue constants will be changed to follow the AB recommended case for IDL constants, i.e. all capital letters. (See http://www.omg.org/docs/ab/98-06-03.pdf, section 2.1.3) So, for example, const TransactionPolicyValue Allows_shared = 0; const TransactionPolicyValue Allows_none = 1; etc. becomes: const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; etc. Revised Text: Change the IDL in section 10.2.4 from: enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, StatusCommitted, StatusRolledBack, StatusUnknown, StatusNoTransaction, StatusPreparing, StatusCommitting, StatusRollingBack }; enum Vote { VoteCommit, VoteRollback, VoteReadOnly }; typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue Allows_shared = 0; const TransactionPolicyValue Allows_none = 1; const TransactionPolicyValue Requires_shared = 2; const TransactionPolicyValue Allows_unshared = 3; const TransactionPolicyValue Allows_either = 4; const TransactionPolicyValue Requires_unshared = 5; const TransactionPolicyValue Requires_either = 6; to: enum Status { StatusActive, StatusMarkedRollback, StatusPrepared, StatusCommitted, StatusRolledBack, StatusUnknown, StatusNoTransaction, StatusPreparing, StatusCommitting, StatusRollingBack }; enum Vote { VoteCommit, VoteRollback, VoteReadOnly }; const IOP::ComponentId TAG_TRANSACTION_POLICY=26; typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; const TransactionPolicyValue REQUIRES_SHARED = 2; const TransactionPolicyValue ALLOWS_UNSHARED = 3; const TransactionPolicyValue ALLOWS_EITHER = 4; const TransactionPolicyValue REQUIRES_UNSHARED = 5; const TransactionPolicyValue REQUIRES_EITHER = 6; Sections 10.3.10 and 10.6 will be changed in the same way. Actions taken: February 23, 2000: received issue ----------------------------- ----------------------------- Issue 3421: CosTSInteroperation not specified (ots-rtf) Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Section 10.3.11 of ptc/99-10-07 shows the CosTSInteroperation module. However, that module does not appear in section 10.6, but should. In general, a sanity check of 10.6 against the rest of the spec seems advisable, so we can be sure that they actually match. Resolution: Change the IDL at the end section 10.3.10 from: const CORBA::PolicyType TransactionPolicyType = 46; interface TransactionPolicy : CORBA::Policy { readonly attribute TransactionPolicyValue tpv; }; to: typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; const TransactionPolicyValue REQUIRES_SHARED = 2; const TransactionPolicyValue ALLOWS_UNSHARED = 3; const TransactionPolicyValue ALLOWS_EITHER = 4; const TransactionPolicyValue REQUIRES_UNSHARED = 5; const TransactionPolicyValue REQUIRES_EITHER = 6; const CORBA::PolicyType TransactionPolicyType = 46; interface TransactionPolicy : CORBA::Policy { readonly attribute TransactionPolicyValue tpv; }; In section 10.6 add this IDL: const CORBA::PolicyType TransactionPolicyType = 46; typedef unsigned short TransactionPolicyValue; const TransactionPolicyValue ALLOWS_SHARED = 0; const TransactionPolicyValue ALLOWS_NONE = 1; const TransactionPolicyValue REQUIRES_SHARED = 2; const TransactionPolicyValue ALLOWS_UNSHARED = 3; const TransactionPolicyValue ALLOWS_EITHER = 4; const TransactionPolicyValue REQUIRES_UNSHARED = 5; const TransactionPolicyValue REQUIRES_EITHER = 6; interface TransactionPolicy : CORBA::Policy { readonly attribute TransactionPolicyValue tpv; }; (Some working drafts of the OTS spec already contain part of this idl in section 10.6, but this just ensures that it is complete and has the correct capitalization in the final version.) Add const IOP::ComponentId TAG_TRANSACTION_POLICY=26; to sections 10.2.4 and 10.6. Revised Text: Actions taken: March 15, 2000: received issue ----------------------------- ----------------------------- Issue 3422: TranactionPolicyValue definition? (ots-rtf) Click here for this issue's archive. Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Page 35 of ptc/99-10-07 shows the TransactionPolicy interface. That interface contains an attribute of type TransactionPolicyValue, but that type is not defined anywhere. Resolution: fixed with changes made by resolution for issue 3421 Revised Text: Actions taken: March 15, 2000: received issue Issue 3423: TransactionalPolicyComponent definition (ots-rtf) Click here for this issue's archive. Source: Object Oriented Concepts (Mr. Michi Henning, michi@ooc.com.au) Nature: Uncategorized Issue Severity: Summary: Page 36 of ptc/99-10-07 defines TransactionPolicyComponent. That type is a struct with a single member. It doesn't make sense to have a structure with only one member, so it would seem advisable to drop the structure. Resolution: Remove the struct TransactionPolicyComponent and roll the remaining constant, TAG_TRANSACTION_POLICY, into the CosTransaction module. Revised Text: Change the IDL in section 10.3.11 from: module CosTSInteroperation { const IOP::ComponentId TAG_TRANSACTION_POLICY=26; struct TransactionPolicyComponent { TransactionPolicyValue tpv; }; }; to: const IOP::ComponentId TAG_TRANSACTION_POLICY=26; Add this IDL to sections 10.2.4 and 10.6: const IOP::ComponentId TAG_TRANSACTION_POLICY=26; Actions taken: March 15, 2000: received issue ----------------------------- ----------------------------- Issue 3559: Transaction policy IDL missing (ots-rtf) Click here for this issue's archive. Source: Hewlett-Packard (Dr. Jishnu Mukerji, jis@fpk.hp.com) Nature: Uncategorized Issue Severity: Summary: The IDL for TransactionPolicy and TransactionPolicyComponent needs to be include in the CosTransaction module. As far as I can tell that is where these belong, since they certainly don't seem to belong anywhere else. They are missing in ptc/99-10-07. I don't know if this has been fixed in a later draft. Resolution: fixed with changes made in resolution for issue 3421 Revised Text: Actions taken: April 13, 2000: received issue ----------------------------- Date: Mon, 1 May 2000 18:18:11 -0700 From: Blake Biesecker To: Michi Henning Cc: ots-rtf@omg.org Subject: Re: [blakeb@gemstone.com: proposed resolutions for issues 3357, 3421, 3422, 3423 & 3559] Message-ID: <20000501181811.A8296@gemstone.com> References: <20000501131935.A4899@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from michi@ooc.com.au on Tue, May 02, 2000 at 10:58:37AM +1000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: da&!!%3[d982M!!i9C!! On Tue, May 02, 2000 at 10:58:37AM +1000, Michi Henning wrote: > On Mon, 1 May 2000, Blake Biesecker wrote: > > > I revised the proposals below to roll TAG_TRANSACTION_POLICY into > > the CosTransactions module. > > One comment. We are currently still discussing whether ALLOWS_NONE should > mean "don't care" or "must not have a transaction". If we settle on the > latter meaning, ALLOWS_NONE should probably be called REQUIRES_NONE instead. > Currently, the messaging changes give a "must not have a transaction" definition. If this changes, we can change the name. We're also considering removing ALLOWS_NONE completly. Since the Policy interogation API is already present, we can add such a proposal to issue 3424's resolution. Do you have time to provide a proposal? Blake > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA >http://www.ooc.com.au/staff/michi-henning.html > Date: Tue, 2 May 2000 11:35:04 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: OTS RTF , messaging-rtf@omg.org Subject: Re: [blakeb@gemstone.com: proposed resolutions for issues >3357, 3421, 3422, 3423 & 3559] In-Reply-To: <20000501181811.A8296@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: bkSd9:@md9!Tmd9oWOe9 On Mon, 1 May 2000, Blake Biesecker wrote: > Currently, the messaging changes give a "must not have a transaction" > definition. If this changes, we can change the name. I'm arguing that, *if* the current interpretation as set by the messaging changes remains in effect, that is, "must not have a transaction", then ALLOWS_NONE is a completely misleading name and should be REQUIRES_NONE instead. Of course, if we decided that objects can't disallow a transaction, then the entire policy is moot and should be removed. > We're also considering removing ALLOWS_NONE completly. Since the > Policy interogation API is already present, we can add such a > proposal to issue 3424's resolution. > > Do you have time to provide a proposal? I don't mind writing a proposal, but I'm still waiting to hear from someone who can tell me what the motivation for adding Allows_None was in the first place. There might an important use case that I'm simply ignorant of, and I don't want to remove a feature until I'm positive that it's not required. Maybe one of the messaging spec authors could help. Q: "What is the use case for permitting a non-transactional object to reject an incoming request on the basis that the request is transactional?" Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Mon, 1 May 2000 18:45:03 -0700 From: Blake Biesecker To: Michi Henning Cc: OTS RTF , messaging-rtf@omg.org Subject: Re: [blakeb@gemstone.com: proposed resolutions for issues 3357, 3421, 3422, 3423 & 3559] Message-ID: <20000501184503.B8296@gemstone.com> References: <20000501181811.A8296@gemstone.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from michi@ooc.com.au on Tue, May 02, 2000 at 11:35:04AM +1000 X-Disclaimer: I only speak for myself, unless I expressly indicate otherwise. Content-Type: text/plain; charset=us-ascii X-UIDL: [Q=!!I%[!![^9e9cXad9 On Tue, May 02, 2000 at 11:35:04AM +1000, Michi Henning wrote: > On Mon, 1 May 2000, Blake Biesecker wrote: > > > Currently, the messaging changes give a "must not have a transaction" > > definition. If this changes, we can change the name. > > I'm arguing that, *if* the current interpretation as set by the messaging > changes remains in effect, that is, "must not have a transaction", then > ALLOWS_NONE is a completely misleading name and should be REQUIRES_NONE > instead. > My apologies. REQUIRES_NONE is a better name if we maintain the current definition. > > Of course, if we decided that objects can't disallow a transaction, > then > the entire policy is moot and should be removed. > > > We're also considering removing ALLOWS_NONE completly. Since the > > Policy interogation API is already present, we can add such a > > proposal to issue 3424's resolution. > > > > Do you have time to provide a proposal? > > I don't mind writing a proposal, but I'm still waiting to hear from > someone > who can tell me what the motivation for adding Allows_None was in > the > first place. There might an important use case that I'm simply > ignorant of, > and I don't want to remove a feature until I'm positive that it's > not > required. > > Maybe one of the messaging spec authors could help. Q: "What is the > use > case for permitting a non-transactional object to reject an incoming > request on the basis that the request is transactional?" > I'd like to see a compelling answer to this question as well. In the absence of one, I think we should propose that ALLOWS_NONE/REQUIRES_NONE be removed. It might also be helpful if we hear from those who think that we should remove ALLOWS_NONE/REQUIRES_NONE. I don't have a good feel about whether we should right up a name change proposal or a proposal to remove ALLOWS_NONE. Blake > Cheers, > > Michi. > -- > Michi Henning +61 7 3891 5744 > Object Oriented Concepts +61 4 1118 2700 (mobile) > Suite 4, 904 Stanley St +61 7 3891 5009 (fax) > East Brisbane 4169 michi@ooc.com.au > AUSTRALIA >http://www.ooc.com.au/staff/michi-henning.html > Date: Tue, 2 May 2000 11:48:54 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: OTS RTF , messaging-rtf@omg.org Subject: Re: [blakeb@gemstone.com: proposed resolutions for issues >3357, 3421, 3422, 3423 & 3559] In-Reply-To: <20000501184503.B8296@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: K7=!!;hXd98k`!!HF(!! On Mon, 1 May 2000, Blake Biesecker wrote: > > Maybe one of the messaging spec authors could help. Q: "What is the use > > case for permitting a non-transactional object to reject an incoming > > request on the basis that the request is transactional?" > > > > I'd like to see a compelling answer to this question as well. In the > absence of one, I think we should propose that ALLOWS_NONE/REQUIRES_NONE > be removed. That's my feeling too, but I'd like to know why it was added in the first place before we do anything rash... Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 05 May 2000 04:41:59 -0700 To: Michi Henning , Blake Biesecker From: Edward Cobb Subject: Re: [blakeb@gemstone.com: proposed resolutions for issues 3357, 3421, 3422, 3423 & 3559] Cc: OTS RTF , messaging-rtf@omg.org In-Reply-To: References: <20000501181811.A8296@gemstone.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: m9md9!BO!!'0&!!"p9!! Comments below. At 11:35 AM 5/2/00 +1000, Michi Henning wrote: >On Mon, 1 May 2000, Blake Biesecker wrote: > >> Currently, the messaging changes give a "must not have a transaction" >> definition. If this changes, we can change the name. > >I'm arguing that, *if* the current interpretation as set by the messaging >changes remains in effect, that is, "must not have a transaction", then >ALLOWS_NONE is a completely misleading name and should be REQUIRES_NONE >instead. > >Of course, if we decided that objects can't disallow a transaction, then >the entire policy is moot and should be removed. > >> We're also considering removing ALLOWS_NONE completly. Since the >> Policy interogation API is already present, we can add such a >> proposal to issue 3424's resolution. >> >> Do you have time to provide a proposal? > >I don't mind writing a proposal, but I'm still waiting to hear from someone >who can tell me what the motivation for adding Allows_None was in the >first place. There might an important use case that I'm simply ignorant of, >and I don't want to remove a feature until I'm positive that it's not >required. > >Maybe one of the messaging spec authors could help. Q: "What is the use >case for permitting a non-transactional object to reject an incoming >request on the basis that the request is transactional?" > I've been trying to remember why we included this use case, but I can't come up with a better reason than completeness. Unless someone else's memory is better than mine (and I wrote the text) or someone else comes up with an understandable use case, I'd be inclined to support removal of allows_none. > Cheers, > > Michi. >-- >Michi Henning +61 7 3891 5744 >Object Oriented Concepts +61 4 1118 2700 (mobile) >Suite 4, 904 Stanley St +61 7 3891 5009 (fax) >East Brisbane 4169 michi@ooc.com.au >AUSTRALIA >http://www.ooc.com.au/staff/michi-henning.html > > > ************************************************************** Ed Cobb, Director, 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: Fri, 28 Jul 2000 17:20:51 -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: Edward Cobb , Bernard Normier , Ram Jeyaraman , ots-rtf@omg.org Subject: Re: formal proposal for 3425] and 3421 References: <3980DEC2.3DB0BFCB@eng.sun.com> <006901bff83b$65a89850$3702400a@bjen> <3.0.5.32.20000728090849.00a2b830@svlhome2.beasys.com> <20000728130748.A28312@gemstone.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3A#!!YER!!_I3!!!iOd9 Blake Biesecker wrote: > > I don't think the original Messaging changes mention which module > the TransactionPolicy interface is in. I just reviewed section > 10.3.11 TransactionPolicy Interface (I believe it was 10.3.10 > before we added TransactionalObject back into the spec) and I > can't explicit mention of which module the idl is in. I always > assumed in was in CosTransactions. > > This RTF has not yet voted on issues relating to TransactionPolicy. > The proposal for issue 3421, which has not been voted on, (and the > original proposal for 3425) assumed that TransactionPolicy was in > the CosTransactions module and made it more explicit. I don't, however, > think it was well thought out. > > Does anyone know what the originally Messaging changes intended? > As for moving forward, we'll need to be explicit about which > module this idl is in (from section 10.3.11 in document ptc/2000-04-06): > > const CORBA::PolicyType TransactionPolicyType = 46; > > interface TransactionPolicy : CORBA::Policy { > readonly attribute TransactionPolicyValue tpv; > }; What I would recommend (assuming that we do want to split this policy into two) is the following: (i) Leave TransactionPolicy as is in the CosTransaction module as is and add a comment stating that it is deprecated. Also change the TransactionPolicyType to TRANSACTION_POLICY_TYPE as in the adopted Messsaging spec. (ii) Define a new Policy type called something like OTSPolicy in the OTS module as: const CORBA::PolicyType OTS_POLICY_TYPE = xx; // to be assigned typedef unsigned short OTSPolicyValue; const OTSPolicyValue ..... define the permissible values here. interface OTSPolicy : CORBA::Policy { readonly attribute OTSPolicyValue pv; }; (iii) Define a new Policy type InvocationSynchPolicy in either Messaging module or CORBA module as deemed appropriate as: const CORBA::PolicyType INVOCATION_SYNCH_POLICY_TYPE = xx; // to be assigned typedef unsigned short InvocationSynchPolicyValue; const InvocationSynchPolicyValue ..... define the permissible values here. interface OTSPolicy : CORBA::Policy { readonly attribute InvocationSynchPolicyValue ispv; }; (iv) Then explain the usage of these new policy types, and also state that the deprecated TransactionpolicyType is being maintained in the standard only for backward compatibility, and new implementations may choose to ignore it and document that fact. No new client of OTS should assume that the deprecated policy is supported in new implementations of OTS. Making the change in this way meets the requirement that the change is backward compatible and does not gratuitiously introduce ambiguity and confusion in the spec. Comments? Jishnu. Date: Sat, 29 Jul 2000 08:26:04 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: OTS RTF Subject: Re: formal proposal for 3425] and 3421 In-Reply-To: <3981F933.39CA0F50@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: -6~e9m9A!!SSX!!iO?e9 On Fri, 28 Jul 2000, Jishnu Mukerji wrote: > > What I would recommend (assuming that we do want to split this > policy > into two) is the following: > > (i) Leave TransactionPolicy as is in the CosTransaction module as is > and > add a comment stating that it is deprecated. Also change the > TransactionPolicyType to TRANSACTION_POLICY_TYPE as in the adopted > Messsaging spec. I agree. > (ii) Define a new Policy type called something like OTSPolicy in the OTS > module as: > > const CORBA::PolicyType OTS_POLICY_TYPE = xx; // to be assigned > > typedef unsigned short OTSPolicyValue; > > const OTSPolicyValue ..... define the permissible values here. > > interface OTSPolicy : CORBA::Policy { > readonly attribute OTSPolicyValue pv; > }; Yes. > (iii) Define a new Policy type InvocationSynchPolicy in either Messaging > module or CORBA module as deemed appropriate as: > > const CORBA::PolicyType INVOCATION_SYNCH_POLICY_TYPE = xx; // to be > assigned > > typedef unsigned short InvocationSynchPolicyValue; > > const InvocationSynchPolicyValue ..... define the permissible values > here. > > interface OTSPolicy : CORBA::Policy { > readonly attribute InvocationSynchPolicyValue ispv; > }; Minor typo: it should be interface InvocationPolicy, not interface OTSPolicy. I would argue that this policy should be in the Messaging module because the issue it addresses is a messaging concern. > (iv) Then explain the usage of these new policy types, and also state > that the deprecated TransactionpolicyType is being maintained in the > standard only for backward compatibility, and new implementations may > choose to ignore it and document that fact. No new client of OTS should > assume that the deprecated policy is supported in new implementations of > OTS. > > > Making the change in this way meets the requirement that the change is > backward compatible and does not gratuitiously introduce ambiguity and > confusion in the spec. > > Comments? Sounds like a nice approach to me. Until PI become official, this means that there is an implicit dependency of the core on OTS because the OTS policy must be enforced in the "client invocation path". [ Thanks for the reminder about the PI status, Jishnu. And, Jeff called me yesterday and was sure to point out the error of my ways :-) ] Once PI spring into existence officially, what you suggest will be clean, because then, the dependency of the core on OTS disappears: messaging checks the invocation policy defined in Messaging, and interceptors check the OTS policy defined in OTS. One question about the intent of the messsaging submitters about the invocation policy: Let's assume we have a 2.4 (or later) ORB with messaging, but without support for OTS. That ORB is used on the client side. Suppose the client wants to invoke on an IOR that doesn't have any OTS policy inside it, but does have an invocation policy inside it. Suppose that invocation policy is SII, but the client makes an AMI invocation on the object. My assumption is that this invocation should still fail, correct? In other words, the core question is: Was the intent of the messaging spec for a target object to prevent an AMI invocation (or an SII invocation) even in the absence of an OTS on either client or server side? If so, we have exactly the right design. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html X-Sender: ecobb@svlhome2.beasys.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 28 Jul 2000 16:15:00 -0700 To: Michi Henning , Jishnu Mukerji From: Edward Cobb Subject: Re: formal proposal for 3425] and 3421 Cc: OTS RTF In-Reply-To: References: <3981F933.39CA0F50@fpk.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: R#Z!!+0md95N,!!~n&!! I was about to respond to Jishnu, but Michi beat me to the punch so I'' try two birds with one response. Comments below. At 08:26 AM 7/29/00 +1000, Michi Henning wrote: >On Fri, 28 Jul 2000, Jishnu Mukerji wrote: > >> >> What I would recommend (assuming that we do want to split this policy >> into two) is the following: >> >> (i) Leave TransactionPolicy as is in the CosTransaction module as is and >> add a comment stating that it is deprecated. Also change the >> TransactionPolicyType to TRANSACTION_POLICY_TYPE as in the adopted >> Messsaging spec. > >I agree. > So do I. >> (ii) Define a new Policy type called something like OTSPolicy in the OTS >> module as: >> >> const CORBA::PolicyType OTS_POLICY_TYPE = xx; // to be assigned >> >> typedef unsigned short OTSPolicyValue; >> >> const OTSPolicyValue ..... define the permissible values here. >> >> interface OTSPolicy : CORBA::Policy { >> readonly attribute OTSPolicyValue pv; >> }; > >Yes. Sounds right. > >> (iii) Define a new Policy type InvocationSynchPolicy in either Messaging >> module or CORBA module as deemed appropriate as: >> >> const CORBA::PolicyType INVOCATION_SYNCH_POLICY_TYPE = xx; // to be >> assigned >> >> typedef unsigned short InvocationSynchPolicyValue; >> >> const InvocationSynchPolicyValue ..... define the permissible values >> here. >> >> interface OTSPolicy : CORBA::Policy { >> readonly attribute InvocationSynchPolicyValue ispv; >> }; > >Minor typo: it should be interface InvocationPolicy, not interface OTSPolicy. > I missed that one, but Michi is correct. >I would argue that this policy should be in the Messaging module because >the issue it addresses is a messaging concern. > I agree with Michi as well on where to define the policy. >> (iv) Then explain the usage of these new policy types, and also state >> that the deprecated TransactionpolicyType is being maintained in the >> standard only for backward compatibility, and new implementations may >> choose to ignore it and document that fact. No new client of OTS should >> assume that the deprecated policy is supported in new implementations of >> OTS. >> >> >> Making the change in this way meets the requirement that the change is >> backward compatible and does not gratuitiously introduce ambiguity and >> confusion in the spec. >> >> Comments? > >Sounds like a nice approach to me. Until PI become official, this means >that there is an implicit dependency of the core on OTS because the >OTS policy must be enforced in the "client invocation path". [ Thanks for >the reminder about the PI status, Jishnu. And, Jeff called me yesterday >and was sure to point out the error of my ways :-) ] > That's true... >Once PI spring into existence officially, what you suggest will be clean, >because then, the dependency of the core on OTS disappears: messaging >checks the invocation policy defined in Messaging, and interceptors check >the OTS policy defined in OTS. > I probably shouln't say this for fear of re-opening a can of worms, but it's not clear that an OTS interceptor that looks like the one defined in the current OTS spec can actually check OTS policy values. Maybe another type of interceptor could. That's for the next round. >One question about the intent of the messsaging submitters about the invocation >policy: > > Let's assume we have a 2.4 (or later) ORB with messaging, but without > support for OTS. That ORB is used on the client side. > Suppose the client wants to invoke on an IOR that doesn't have > any OTS policy inside it, but does have an invocation policy inside > it. Suppose that invocation policy is SII, but the client makes > an AMI invocation on the object. > > My assumption is that this invocation should still fail, correct? > Yes, it should. > In other words, the core question is: Was the intent of the messaging > spec for a target object to prevent an AMI invocation (or an SII > invocation) even in the absence of an OTS on either client or server > side? > That's what I thought we were trying to achieve. Other messaging submitters can also comment. >If so, we have exactly the right design. > Gosh, we were brilliant :-) > Cheers, > > Michi. >-- >Michi Henning +61 7 3891 5744 >Object Oriented Concepts +61 4 1118 2700 (mobile) >Suite 4, 904 Stanley St +61 7 3891 5009 (fax) >East Brisbane 4169 michi@ooc.com.au >AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html > > > ************************************************************** 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: Fri, 28 Jul 2000 17:59:48 -0700 From: Jonathan Biggar Organization: Floorboard Software X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Jishnu Mukerji , OTS RTF Subject: Re: formal proposal for 3425] and 3421 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: @Tgd9@bC!!d*a!!PmE!! Michi Henning wrote: > One question about the intent of the messsaging submitters about the invocation > policy: > > Let's assume we have a 2.4 (or later) ORB with messaging, but without > support for OTS. That ORB is used on the client side. > Suppose the client wants to invoke on an IOR that doesn't have > any OTS policy inside it, but does have an invocation policy inside > it. Suppose that invocation policy is SII, but the client makes > an AMI invocation on the object. > > My assumption is that this invocation should still fail, correct? > > In other words, the core question is: Was the intent of the messaging > spec for a target object to prevent an AMI invocation (or an SII > invocation) even in the absence of an OTS on either client or server > side? > > If so, we have exactly the right design. Can anyone explain to me why this is at all useful behavior? If transactions aren't part of the equation, and the server can't tell whether an invocation was via SII, DII, AMI or TII, what in the heck is it doing trying to prohibit some types of invocations? -- Jonathan Biggar jon@floorboard.com jon@biggar.org Date: Sat, 29 Jul 2000 11:14:09 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Jishnu Mukerji , OTS RTF Subject: Re: formal proposal for 3425] and 3421 In-Reply-To: <39822C84.EEEDDFE2@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ^NC!!^Jpd9Z2/!!aUIe9 On Fri, 28 Jul 2000, Jonathan Biggar wrote: > Can anyone explain to me why this is at all useful behavior? If transactions > aren't part of the equation, and the server can't tell whether an invocation was > via SII, DII, AMI or TII, what in the heck is it doing trying to prohibit some > types of invocations? If you want to enforce the invocation policy only in the presence of transactions, then the core has a dependency on OTS, even for those ORBs that don't intend to ever support OTS. In addition, once PI become real, to avoid the dependency, you'd have to write the OTS interceptor to enforce both the invocation policy and the OTS policy. However, an interceptor doesn't have enough information to do that. The only clean solution I can see is to enforce the invocation policy as a concept that is unrelated to OTS, and to enforce it always. For ORBs that are not OTS aware, the default invocation policy value would be ANY (and that default would be assumed if no invocation policy is in the IOR). Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Fri, 28 Jul 2000 18:30:11 -0700 From: Jonathan Biggar Organization: Floorboard Software X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Jishnu Mukerji , OTS RTF Subject: Re: formal proposal for 3425] and 3421 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: gN9!!^iV!!%i`d93O?!! Michi Henning wrote: > On Fri, 28 Jul 2000, Jonathan Biggar wrote: > > > Can anyone explain to me why this is at all useful behavior? If >transactions > > aren't part of the equation, and the server can't tell whether an >invocation was > > via SII, DII, AMI or TII, what in the heck is it doing trying to >prohibit some > > types of invocations? > > If you want to enforce the invocation policy only in the presence of > transactions, then the core has a dependency on OTS, even for those >ORBs > that don't intend to ever support OTS. In addition, once PI become >real, > to avoid the dependency, you'd have to write the OTS interceptor to > enforce both the invocation policy and the OTS policy. However, an >interceptor > doesn't have enough information to do that. > > The only clean solution I can see is to enforce the invocation >policy as > a concept that is unrelated to OTS, and to enforce it always. For >ORBs > that are not OTS aware, the default invocation policy value would be >ANY > (and that default would be assumed if no invocation policy is in the >IOR). So the answer is that it doesn't make sense if the server is not using OTS, but is necessary for separation of concerns. If that is true, perhaps I can buy it. Second question: Isn't TII actually the thing here that needs to be controlled, not the other AMI methods? Can't we get the same effect with an enum for { TII_ALLOWED, TII_NEVER, TII_ALWAYS }? -- Jonathan Biggar jon@floorboard.com jon@biggar.org Date: Sat, 29 Jul 2000 11:50:45 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Jishnu Mukerji , OTS RTF Subject: Re: formal proposal for 3425] and 3421 In-Reply-To: <398233A2.2E0219B4@floorboard.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: `KK!!e^^!!61Pd97G"!! On Fri, 28 Jul 2000, Jonathan Biggar wrote: > So the answer is that it doesn't make sense if the server is not using OTS, but is > necessary for separation of concerns. If that is true, perhaps I can buy it. > > Second question: Isn't TII actually the thing here that needs to be controlled, not > the other AMI methods? Can't we get the same effect with an enum for { TII_ALLOWED, > TII_NEVER, TII_ALWAYS }? Hmmm... A TII with a timeout of 1 second is the same as a slightly slow AMI. In other words, I'm not sure that the distinction makes sense. Cheers, Michi. -- Michi Henning +61 7 3891 5744 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 904 Stanley St +61 7 3891 5009 (fax) East Brisbane 4169 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html