Issue 2353: Issue: create_policy explanation (messaging-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Issue: The definition of ORB::create_policy has led to some confusion. Clarify how specifications can make use of this operation. Resolution: Close the issue Revised Text: Actions taken: January 28, 1999: received issue October 3, 2001: closed issue Discussion: This issue, along with Jon Goldberg's proposed resolution has already been resolved. The proposed text now resides in section 4.8.5 of the 2.4 CORBA Spec. Close the issue End of Annotations:===== Date: Thu, 28 Jan 1999 00:24:44 -0800 From: "Jon Goldberg" Reply-To: goldberg@inprise.com X-Accept-Language: en To: messaging-rtf@omg.org CC: orb_revision@omg.org, issues@omg.org Subject: Issue: create_policy explanation Issue: The definition of ORB::create_policy has led to some confusion. Clarify how specifications can make use of this operation. Proposed Resolution: Delete the last sentence of section 5.2.3.1 and add the following text: When new PolicyTypes are added to CORBA specifications, the following details must be defined. It must be clearly stated which particular uses of a new policy are legal and which are not: o Specify the assigned CORBA::PolicyType and the policy's interface definition. o If the Policy can be created through CORBA::ORB::create_policy, specify the allowable values for the any argument 'val' and how they correspond to the initial state/behavior of that Policy (such as initial values of attributes). For example, if a Policy has multiple attributes and operations, it is most likely that create_policy will receive some complex data for the implementation to initialize the state of the specific policy: //IDL struct MyPolicyRange { long low; long high; }; const CORBA::PolicyType MY_POLICY_TYPE = 666; interface MyPolicy : Policy { readonly attribute long low; readonly attribute long high; }; If this samply MyPolicy can be constructed via create_policy, the specification of MyPolicy will have a statement such as: "When instances of MyPolicy are created, a value of type MyPolicyRange is passed to CORBA::ORB::create_policy and the resulting MyPolicy's attribute 'low' has the same value as the MyPolicyRange member 'low' and attribute 'high' has the same value as the myPolicyRange member 'high'. o If the Policy can be passed as an argument to POA::create_POA, specify the effects of the new policy on that POA. Specifically define incompatibilities (or inter-dependencies) with other POA policies, effects on the behavior of invocations on objects activated with the POA, and whether or not presence of the POA policy implies some IOR profile/component contents for object references created with that POA. If the POA policy implies some addition/modification to the object reference it is marked as "client-exposed" and the exact details are specified including which profiles are affected and how the effects are represented. Typically, the Messaging::TAG_POLICIES component is used to carry this information. o If the Policy can be set within a client to tune the client's behavior, specify the policy's effects on the client specifically with respect to (a) establishment of connections and reconnections for an object reference; (b) effects on marshaling of requests; (c) effects on insertion of service contexts into requests; (d) effects upon receipt of service contexts in replies. In addition, incompatibilities (or inter-dependencies) with other client-side policies are stated. For policies that cause service contexts to be added to requests, the exact details of this addition (probably to the Messaging::INVOCATION_POLICIES service context) are given. o If the Policy can be used with POA creation to tune IOR contents and can also be specified (overriden) in the client, specify how to reconcile the policy's presence from both the client and server. It is strongly recommended to avoid this case! As an excercise in completeness, most POA policies can probably be extended to have some meaning in the client and vice versa, but this does not help make usable systems, it just makes them more complicated without adding really useful features. There are very few cases where a policy is really appropriate to specify in both places, and for these policies the interaction between the two must be described. o Pure client-side policies are assume to be immutable. This allows efficient processing by the runtime that can avoid re-evaluating the policy upon every invocation and instead can perform updates only when new overrides are set (or policies change due to rebind). If the newly specified policy is mutable, it must be clearly stated what happens if non-readonly attributes are set or operations are invoked that have side-effects. o For certain policy types, override operations may be disallowed. If this is the case, the policy specification must clearly state what happens if such overrides are attempted. Sender: jis@fpk.hp.com Message-ID: <38F628C8.CE456E1B@fpk.hp.com> Date: Thu, 13 Apr 2000 16:06:32 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777) MIME-Version: 1.0 To: messaging-rtf@omg.org Subject: Issue 2353 has already been resolved in Core Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 'f;!!lm*e9$iYd9e6e!! Hence can be gotten rid of from the messaging rtf list. Jishnu. _____________________________________________________________________________- Issue 2353: Issue: create_policy explanation (messaging-rtf) Click here for this issue's archive. Nature: Uncategorized Issue Severity: Summary: Summary: Issue: The definition of ORB::create_policy has led to some confusion. Clarify how specifications can make use of this operation. Resolution: Revised Text: Actions taken: January 28, 1999: received issue Discussion: Date: Tue, 20 Mar 2001 17:58:45 -0500 From: Jishnu Mukerji 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: orb_revision@omg.org Subject: Issue 2353 proposed resolution Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \T8e9U^Ke9/ma!!TIOe9 Issue 2353: Issue: create_policy explanation (messaging-rtf) Click here for this issue's archive. Nature: Uncategorized Issue Severity: Summary: The definition of ORB::create_policy has led to some confusion. Clarify how specifications can make use of this operation. Resolution: This issue, along with Jon Goldberg's proposed resolution has already been resolved. The proposed text now resides in section 4.8.5 of the 2.4 CORBA Spec. Close the issue Revised Text: Actions taken: Close no change ________________________________________________________________ Unless we hear a signficant reason to do otherwise, this proposal will be on the upcoming vote. Jishnu.