[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DynamicAttributeService
Carol,
> Hi,
>
> Item 2
>
> DynamicAttributeService get_dynamic_attributes()
>
> This method takes a PolicyEvaluatorList as an input parameter... however
> there are no methods on PolicyEvaluator that make sense for a
> DynamicAttributeService to call. Since we agreed that PolicyEvaluators are
> "replaceables" - they may be provided by different vendors and implement
> different access policies, it isn't reasonable to expect that hidden
> methods here would be very useful. :-) For this reason, I suggest we
> remove this parameter for the initial submission and revisit the
> performance considerations that were the catalyst for providing these refs
> to the DynamicAttributeService there after the initial submission.
I agree with your suggestion to remove the parameter. I believe it was a typo.
According to what I understood in the meeting the get_dynamic_attributes should
take only resource name, operation name, and static attributes.
> ==
> Item 3:
> Also on DynamicAttributeService
>
> We agreed that the dynamic attribute service would encapsulate any
> "callbacks" to the application when necessary. This would be for the
> purpose of determining how to create the new AttributeList that includes
> the appropriate static and dynamic attributes to be passed to the other
> HRAC evaluator objects. We also agreed - I think - that
> DynamicAttributeService is a "singleton" object. I believe we need to
> consider providing a standard way that a 3rd party application vendor can
> register a dynamic attribute evaluator with the DynamicAttributeService for
> a ResourceName.
It should be a part of admin interface on DynamicAttributeService. I think we
agreed to postpone specification of that interface until the revised
submission.
Konstantin
----------------
Broadcast message to hrac-rfp from Konstantin Beznosov <beznosov@baptisthealth.net>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.