Raw notes from DC meeting

[Rod Widdowson]

> 	- ask Rod to define current resolver and filter input/output
contract

I can put this in the wiki wherever you wish, but for now:

1) Attribute Resolver.

All "flow" (non injected) input is via an AttributeResolutionContext.  This
is what is fed into the Attribute Resolution Engine

1a) Input:
 - A list of "to be resolved" attributes can be provided via the context.
 - Certain Attribute Resolvers require that the context has as a child
"AttributeRecipientContext".  This is a convenience mechanism which I am not
yet convinced is correct (we may just chose to push the contents into the
resolution context).  It is purely there to provide the PrinicipalName,
AttributeIssuerID and AttributeRecipientID to the resolvers.
 - It is likely that similar information like this will be required as input
to the templates provided to the LDAP and RDBMS Data Connectors.
 - The scripted Attribute resolver is capable of traversing the context
tree.

1b) Output
- The AttributeResolutionContext can be interrogated to get hold of the
resolved attributes (#getResolvedAttributes())

2) Attribute Filter.

All flow input is via an AttributeFilterContext. This is what is fed into
the Attribute Filter Engine.

2a) Inputs
 - The resolved attributes are inserted into the context
(#setPrefilteredAttributes()).
 - Certain filters require an AttributeRecipientContext (as per the
Resolver).  Locating this is delegated to a helper class, which currently
looks for a peer AttributeResolutionContext and within that a child
AttributeRecipientContext.  Again I am not yet convinced that this is
correct.
- The scripted Attribute filters are capable of traversing the context tree.

2b) Outputs
 - The AttributeFilterContext is interrogated for filtered attributes and
their values (#getFilteredAttributes())


/R