Rather than continue to hijack Peter's thread, I'll move to a new one. The context starts here
> > I guess that the end goal is that the deployer "just" defines a few attributes
> > with well known names and the Federation supplied information controls the
> > rest (encoding, display, filtering and so on).
> The basic idea is to provide a separate recipe for as many attributes and their metadata as possible,
> and then just "connect" up the attributes from the resolver with those definitions, either by assuming
> the IDs line up by convention or by just attaching the ID to the attribute in the resolver some how
> that's not confusing. I haven't really worked it out beyond the general idea that anything that's
> currently "inside" the <AttributeDefinition> element at the top level would be something we'd
> want to factor out.
I was thinking about this this morning and at the risk of stating the blindingly obvious what is needed is an
AttributeDictionaryService which "does the usual" with respect to a new AttributeDictionary Interface. This can initially be
implemented either by the AttributeResolverImpl Service or (perhaps better) by a shim service which takes the
AttributeResolverService as a parameter.
So "all" we need to do in V4.0.0 is to define precisely what the AttributeDictionary does. A start point will be "resolvers for
everything currently inside the AttributeDefinition".
There's obvious a bit of work to turn the attribute resolvers inside out like that and the rewire the encoders and UI components to
the new service, but we would then be in a position to plug in a completely different service which looks at a "real Dictionary" and
think about pensioning off non relevant parts of the AttributeDefintion language.
What's not obvious to me is how we wide this Interface in V4 without changing the API. It doesn't seem to me that the new java
support will help here, but I also suspect that when we have the need the mechanism will become obvious. Worst case we need to have
two different service interfaces and have our implementation implement both.
> So "all" we need to do in V4.0.0 is to define precisely what the
> AttributeDictionary does. A start point will be "resolvers for everything
> currently inside the AttributeDefinition".
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.
> What's not obvious to me is how we wide this Interface in V4 without changing
> the API.
Not sure I follow that.
As a general matter, the main trick Java 8 added is that you can now add methods to interfaces that have default implementations so it's possible to compatibly change them in some cases without breaking anybody's code. They're just gradually turning it into a multiple inheritance language without actually coming out and saying it, but I don't think it's meant to be good practice to bury lots of implementation code in interfaces, it's just a tool to make evolving APIs a bit more tractable.
> As a general matter, the main trick Java 8 added is that you can now add methods to interfaces that
> have default implementations so it's possible to compatibly change them in some cases without
> breaking anybody's code.
Yea, I think I meant that I couldn't see how that could be used in this case - with the added twist that once we put an
implementation into an Interface (which is by its nature an API) we have to stand by it somehow.
But I think that I also meant that until we had a need we wouldn't know whether it worked or not, and that even if it didn't there
were other ways of achieving what we need.
Certainly default implementations will be a very useful tool for the duration of V4...
> 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
And in 3.4 the default AttributeDirectoryService implements resolveAttributeEncoders(prc, attribute) as
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
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
> 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....
It wasn't in my list of priorities to play with it at all since I didn't think it would be close enough to a real answer at this stage to be more than conceptual overhead.
I think at minimum you'd have to tackle the display name and description stuff also.
My suspicion is that the "right" API hub for this is IdPAttribute as the input object. It defers the question of how we're going to tie the layers together without precluding it just being getId().