Profile config strategy

[Cantor, Scott]

On 12/16/13, 4:04 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>I think I need to see/imagine a worked example since I tend to end up
>with a
>"it depends" depending on the case - for instance it seems stupid to have
>a
>whole set/getter bean just to add a new encryption type (if that is a
>relevant example) and at the other end of the spectrum one is adding
>something so large that one is probably looking at a sub version change...

Part of it is choosing good property design to minimize change.

The main cost of moving the config interfaces/classes out of -api is that
somebody not us doing their own SAML profile handler would not have common
code to rely on to handle profile configuration, and would be copying code.

I'm not sure how likely that scenario is, to be honest, nor am I convinced
that any non-SAML protocol support is going to involve the kind of design
and factoring of configuration layers that SAML does. Most of that comes
from the multi-version aspect of supporting both SAML versions.

So I think I'd rephrase my original question to whether we care about
exposing that code to extensions or if we can just leave the config API
internal to our implementation.

>My problem here is that the xml file itself is not backwards compatible.
>Either class name is not found in the earlier version of the jar and we
>die,
>or the setter doesn't exist in the earlier version or the class and we
>die...

Yes, that's true. It's an API of sorts regardless of where it lives. But
there's still more flexibility when you can maintain those classes
internally and create extended versions or implement compatibility
work-arounds as an implementation detail rather than in the public API.

For now, I'm not changing anything, just creating the missing interfaces
and cleaning up the code.

-- Scott