Profile config strategy

[Cantor, Scott]

Before getting serious about the profile handling code, the main stumbling
block for me is whether to maintain the class hierarchy and hardwired
classes in the API layer for the properties that configure the profiles.

These are classes in net.shibboleth.idp.saml.profile.config.*

Being up front, I always took a different approach to this in the SP, I
much preferred having a generic typed property API that I could attach any
properties to at runtime, and I look up properties by string name. I did
that to avoid API changes any time I added properties, particularly to
avoid having the ABI change just to add a setting that would address a bug
or something like that.

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.

I figure there are performance and design arguments against using bean
accessors and reflection to access this information, and the idea would be
soundly hated, but I really don't care for having these hardwired API
classes carrying the settings either.

-- Scott