<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 6/2/15 9:40 AM, Cantor, Scott wrote:<br>
</div>
<blockquote cite="mid:6D492B62-71E2-4EF7-B2D8-D0349E7794CF@osu.edu"
type="cite">
<pre wrap="">On 6/2/15, 9:15 AM, "dev on behalf of Marvin Addison" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofmarvin.addison@gmail.com"><dev-bounces@shibboleth.net on behalf of marvin.addison@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Offhand, it seems there's an easy solution: make three different Criterion classes, one for each type, then give CriteriaSet intelligence to do any/all/other combinations for multiple matches. I guess I'm making an academic argument at this point since I clearly haven't spent as much time as you have, so I'll just trust that the current design is best for the given cases.
</pre>
</blockquote>
<pre wrap="">
You can have three different classes, but they can't implement a common generic interface. You end up where we are, supporting explicit Criterion classes, so it's not really much of a change.</pre>
</blockquote>
<br>
Yes. I leapt over this logical consequence in my original message
b/c I thought it was obvious but: making the caller supply all 3
predicate types seems bad, because it means the caller has to know
all about the internal impl details of the resolver. Which in
reality it can't. So you pass a single criterion holding data
(only), and let the resolver decide how to evaluate that. In the
abstract filtering credential resolver case, it does map them to
predicates which it can then eval.<br>
<br>
<br>
<blockquote cite="mid:6D492B62-71E2-4EF7-B2D8-D0349E7794CF@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">That seems odd to me. What's the point of caller having control over criteria if he/she doesn't know what types are in play for criteria evaluation?
</pre>
</blockquote>
<pre wrap="">
Because the types in play are the business of the resolver. You might know some or all of the public types involved, but the internal implementation may be entirely different. If you stored metadata in a database, you would never want to evaluate an entityID criterion by running a Predicate over EntityDescriptor, you'd issue a select. You need an actual EntityIDCriterion to give you the where clause.</pre>
</blockquote>
<br>
<br>
Exactly, that's the "lookup" criterion vs "predicate" criterion
issue. You can't know what a resolver needs. See my last note re:
a batch metadata resolver vs a dynamic one.<br>
<br>
Another example is a chaining TrustEngine where the first in the
chain is an explicit key engine that uses the criteria to lookup
trusted Credentials from a CredentialResolver, and the second in the
chain needs to use the same criteria to lookup
PKIXValidationInformation for PKIX CertPath eval. Either the
criteria has to just be data that is evaled by the trust engine as
appropriate, or else you have to pass 2 completely duplicate sets of
Predicates - which in reality you can't since the caller won't even
necessarily know what TrustEngines impls are in use, or the impl
details of each.<br>
<br>
The only reasonable thing I think a caller can expect vis-a-vis
Predicates is: if you have FooResolver which returns instances of
Foo, then it's not unreasonable to support passing in some instances
of Predicate<Foo>, to filter the results. (What the
CredentialResolvers currently support.) Anything else is exposing
too much resolver impl detail to the caller, IMHO.<br>
<br>
But as I've argued, you can't really support passing *only*
predicates, unless the pre-filter collection of candidates is known
to be small enough to support efficient evaluation. And that's in
general not a valid assumption for a batch metadata resolver.<br>
<blockquote cite="mid:6D492B62-71E2-4EF7-B2D8-D0349E7794CF@osu.edu"
type="cite">
</blockquote>
<br>
</body>
</html>