Profile config strategy

[Rod Widdowson]

As I have thought my way through this mail I have changed my mind several
times...

My first observation is that all those classes in in
net.shibboleth.idp.saml.profile.config.* should be interfaces.  Which of
course doesn't change anything but makes it easier for me to reason around
the next stage which is to truly internalize this statement

> What I was wondering was whether using the Java Bean APIs would be a way
> to move the actual profile config classes out of -api, but still maintain
> them as the substrate for carrying the properties.

So the -impl can add more getters via an extended interface which the
consumers of the impl can check for (with sensible defaults).  This makes a
lot of sense to me.  I would not be against adding the extended interface
into -api as a 'statement of intent', but that might not be allowable by our
version policy.

Or more interest to me is how the actual configuration file will work - I'm
guessing that more people will care about backwards compatibility of
configuration files than of APIs.  If it is a proprietary parser then it is
easy, but my observation that providing Spring with

p:newParam="newParam"

when the bean doesn't have a #setNewParm() tends to end badly, so we need a
plan to deal with that.   There are lots of ways of dealing with that, which
we don’t need to go into here.

Finally, I note that the config class hierarchy goes:

SAML2mumble extends SAMLmumble extends BasicMumble

And I'll mention for the record (Scott knows this 'cos he fixed the last
one) that we need to keep an eye open for things which are kinda-sorta
similar between SAML1 and SAML2 and so have properties in SAMLmumble when in
fact they are different and need to be represented at the top level - the
last example was the namespace/format combination in the encoders..

Rod