No subject

[Marvin Addison]

I'd like to float an ambitious (and possibly presumptuous) API change to
Criterion that seems to me would facilitate extension. I've reviewed use of
CriteriaSet/Criterion in the MetadataResolver and TrustEngine, and in both
cases the sorts of Criteria handled by the components are fixed and
immutable. It seems to me that you could get extension for free by
inverting the logic; instead of the component doing the test, let Criterion
provide a match/predicate function that returns a boolean indicating
whether or not the criteria matches a given input. In that view Criterion
probably ought to be generified thus:

class Criteria<T> {
  boolean matches(T input);
}

By putting the matching logic in the Criteria predicate style, you don't
have to know a priori what sorts of criteria you need to support other than
basic type checking.

I see some TODO comments in AbstractBatchMetadataResolver that seem like
they could benefit from this approach. Additionally, I have a use case in
IDP-701 that could benefit as well; I need to implement some creative logic
to look up an EntityDescriptor when I don't have a true Entity ID provided
by a SAML protocol message. Being able to define a custom Criterion seems
like the ideal approach.

M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20150601/1c24fc85/attachment.html>