Attribute Dictionary & V4.0

[Rod Widdowson]

> I hesitate to simplify it to that degree because I have a tendency to want to turn 
> everything into service abstractions like that, but that's
> pretty much my mental model, yes.

Yea, well we can piggyback it on another service if needs be, but a mostly quiescent extra thread and minimal configuration if you
don’t care doesn’t seem to be a big price to play, by way of contrast I just counted the number of threads in a freshly booted
Win10/RS4 machine and got bored at 1000.

As I was mulling this over this morning and it seems to me that there is no reason to not start down this rout in 3.4 (if we really
wanted), that would help the API-shock in 4.0.

If we consider the encoding case, the critical line (in AddAttributeStatementToAssertion) is 

	Set<AttributeEncoder<?>> encoders = attribute.getEncoders();

We "just" need to turn this into

	Set<AttributeEncoder<?>> encoders = null;
	if (null != attributeDirectoryService) {
	   encoders = attributeDirectoryService.resolveAttributeEncoders(prc, attribute);
	}
	if (encoders==null) {
	    encoders = attribute.getEncoders();
	}

And in 3.4 the default AttributeDirectoryService implements resolveAttributeEncoders(prc, attribute) as

	return attribute.getEncoders();

The rest is plumbing deep in the impl layer, exposable if we wanted.

A better API for the AttributeDirectoryService#resolveAttributeXYZ would be to take a String (the idpName).  

In this case the default code to implement it would need (in 3.4) to be co-located with AttributeResolverImpl, which might in turn
require some fleet footwork to ensure that if people have plumbed in their own implementation of AttributeResolver the right thing
happens.

Is this something we even want to think about prototyping for 3.4?  Apart from allowing us to kick the wheels early, the only
advantage would be to give all those hundreds of people writing their own Attribute Management subsystems advance notice on our
plans....

Rod