[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DynamicAttributeService



Carol wrote:

>> 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.

Konstantin replied:

>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.

Carol replied:

>I may be wrong, but I think it was John who wanted this parameter... the
>context was the ability to provide some shortcuts for performance
>enhancements in the implementation.  Anyway, I am planning to remove it for
now.

Actually, not me. I suggested the addition of "operation" to the
get_dynamic_attributes() parameter list for possible implementation
performance enhancements. I recall that we all just somehow "naturally" felt
that PolicyEvaluatorList should be an argument when we opted for having
replacable evaluators. I don't recall any discussion on the point. It is
possible that there could be other dynamic attributes in the
DynamicAttributeService which are not needed by the evaluators in
PolicyEvaluatorList. So, why find/return them. This consideration may be
what we sensed in Austin.

In any event, Carol's point about there being no methods pertinent to the
DynamicAttributeService is well taken. Leaving PolicyEvaluatorList as a
parameter to get_dynamic_attributes() is one way to leave a marker for
Carol's point. If it is removed as a parameter in the initial submission,
somehow Carol's question should be noted as unresolved.

jb


----------------
Broadcast message to hrac-rfp from "jb" <jbarkley@nist.gov>.
Go to http://cadse.cs.fiu.edu/omg/hrac-rfp to browse the mail list archive.