Issue 3357: OTS-RTF issue: spelling/case of transaction policy values (ots-rtf) Source: ZeroC (Mr. Bernard Normier, bernard@zeroc.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: see above Revised Text: Actions taken: February 23, 2000: received issue February 27, 2001: closed issue Discussion: Since TransactionPolicyValue has been deprecated as part of the resolution for issue 3425, this issue is being closed without action. End of Annotations:===== >From: "Bernard Normier" To: Subject: OTS-RTF issue: spelling/case of transaction policy values Date: Wed, 23 Feb 2000 17:01:18 -0500 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: #!c!!1KV!!UW:e9$J7e9 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. Regards, Bernard 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: Tue, 2 May 2000 10:58:37 +1000 (EST) From: Michi Henning To: Blake Biesecker cc: ots-rtf@omg.org Subject: Re: [blakeb@gemstone.com: proposed resolutions for issues 3357, 3421, 3422, 3423 & 3559] In-Reply-To: <20000501131935.A4899@gemstone.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: \_Fe962]d9$]!!!A$6e9 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. 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: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 **************************************************************