Issue 2637:  Policy Manager and Policy Current (messaging-rtf)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: In keeping with the general approach of moving things into their own
 modules and out of the CORBA module to allow ease of independant
 evolution etc. I would like to propose that the PolicyManager and
 PolicyCurrent interfaces be moved out of the CORBA module into their own
 module called perhaps PolicyManagement or some such. This sort of
 partitioning makes it easier to deal with versioning issues related to
 inclusion of parts of CORBA in JDK etc.
 
 Coming to think of it, perhaps, eventually, all Policy factory related
 operations, ORB::create_policy comes to mind, should be moved into their
 own PolicyFactory interface and placed in the PolicyManagement module,
 but for now it can stay where it is. For obvious reasons the
 CORBA::Policy interface and the Object operations related to Policy need
 to remain where they are for now.
 

Resolution: Too signficant and backward incompatible change. Close this one no change
Revised Text: 
Actions taken:
May 6, 1999: received issue
October 3, 2001: closed issue
Discussion: 

End of Annotations:=====
Sender: jis@fpk.hp.com
Date: Wed, 05 May 1999 17:15:28 -0400
From: Jishnu Mukerji <jis@fpk.hp.com>
Organization: Hewlett-Packard EIAL
To: issues@omg.org
Subject: Policy Manager and Policy Current

(Messaging RTF issue) doc# orbos/98-05-05

In keeping with the general approach of moving things into their own
modules and out of the CORBA module to allow ease of independant
evolution etc. I would like to propose that the PolicyManager and
PolicyCurrent interfaces be moved out of the CORBA module into their
own
module called perhaps PolicyManagement or some such. This sort of
partitioning makes it easier to deal with versioning issues related to
inclusion of parts of CORBA in JDK etc.

Coming to think of it, perhaps, eventually, all Policy factory related
operations, ORB::create_policy comes to mind, should be moved into
their
own PolicyFactory interface and placed in the PolicyManagement module,
but for now it can stay where it is. For obvious reasons the
CORBA::Policy interface and the Object operations related to Policy
need
to remain where they are for now.

The proposal above is exactly analogous to what was done with Dynamic
Any in the Core RTF 2.4, and hence I raise this issue to see if it
would
be feasible to do similar cleanup with the Policy framework in
Messaging.

Of course, if we knew any better while we were writing the Security
spec, an alternative cleaner approach would have been to not add any
policy related operations to the Object pseudo-interface, but instead
simply use additional Object scoped set and get override and get
policy
operations in the PolicyManager which takes an Object as one of its in
parameters, but then that is probably much water over the dam already,
since the damage was started by Security 4 years ago.

Jishnu.
-- 
Jishnu Mukerji
Systems Architect

Email: jis@fpk.hp.com         Hewlett-Packard EIAL,
Tel:  +1 973 443 7528         300 Campus Drive, 2E-62,
Fax:  +1 973 443 7422         Florham Park, NJ 07932, USA.

Date: Tue, 20 Mar 2001 18:22:16 -0500
From: Jishnu Mukerji <jishnu_mukerji@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: orb_revision@omg.org
Subject: Issue 2637 proposed resolution
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: Wn;e9E`p!!+S3e9!,S!!

Issue 2637: Policy Manager and Policy Current (messaging-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: In keeping with the general approach of moving things into
their own modules and out of the CORBA module to allow ease of
independant evolution etc. I 
would like to propose that the PolicyManager and PolicyCurrent
interfaces be moved out of the CORBA module into their own module
called
perhaps PolicyManagement 
or some such. This sort of partitioning makes it easier to deal with
versioning issues related to inclusion of parts of CORBA in JDK etc.
Coming to think of it, perhaps, 
eventually, all Policy factory related operations, ORB::create_policy
comes to mind, should be moved into their own PolicyFactory interface
and placed in the 
PolicyManagement module, but for now it can stay where it is. For
obvious reasons the CORBA::Policy interface and the Object operations
related to Policy need to 
remain where they are for now.
Resolution: Too signficant and backward incompatible change. Close
this
one no change.
Revised Text:
Actions taken: Close no change
___________________________________________________________________

Unless someone has a significant objection needing further discussion,
this proposal will appear on the next vote.

Thanks,

Jishnu.