AttributeResolver and Resolver API

[Cantor, Scott]

On 12/7/13, 2:55 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>
>Before yesterday's dev call, my criteria for accepting that
>AttributeResolver does not extend Resolver is time, meaning, the use
>of "resolver" may have meant different things at different times in
>the development cycle. Kind of like a knot in a clear piece of wood,
>character.

That's basically true, because the use of the term Resolver as a catch-all
for searching for things was something Chad added in the early V3 design
work. I think Brent used it in various security-related places, and I used
it in the SP for things like turning KeyInfo blobs into keys or
certificates (which may have been me copying Brent, don't remember). And I
used it (again maybe just copying) in the CredentialResolver piece that
resolves private keys.

We always called the attribute resolver by that name.

We never used the term for things like metadata lookup or session caches.

>But on yesterday's dev call, the notion of a resolver as a "searcher"
>made me feel better. It took a while for the mud to settle in my mind
>afterwards, but I believe we were saying that a resolver searches
>through its cache of data. To me, that sounds like a "static
>resolver", which performs a lookup.

It doesn't have to be static necessarily, but I think it's used in
java-support mean anything that applies some kind of search criteria to a
lookup process.

The AttributeResolver only does that in a very loose sense.

>This morning though, it seems to me that the core plugin to an
>AttributeResolver is the DataConnector, for which the most primary
>seem LDAP and RDBMS, which themselves perform searches and queries.
>And DataConnector extends ResolverPlugin, which I've already said
>seems like a fit for Resolver.

Possibly. I didn't notice we had a ResolverPlugin base class.

>So I am left thinking an AttributeResolver fits our criteria for a
>"dynamic resolver" which performs searches, in contrast to a "static
>resolver" which performs lookups.

The dynamic/static distinction is not, I think, a significant one.

But the one that is, is the interface to the functionality, which in the
case of AttributeResolver is a profile context based process.

But you may be right about the ResolverPlugin case. If it's returning a
collection of something, that could well be adapted easily.

>My thinking on this is probably tainted by my thinking that Resolver
>methods would be appropriate for provisioning via an
>AttributeResolver, since sometimes you may want to resolve one
>attribute value or maybe 100k. Otherwise, I don't think we expose the
>concept of multi-valued vs single-valued attributes in
>attribute-resolver.xml.

No, but we do support resolving specific attributes to some degree.

-- Scott