Profile config strategy

[Tom Zeller]

> 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.

It seems that profile configuration properties _should_ be in the API
since those are the knobs that users tweak. The class hierarchy seems
to fit the rest of the Java code, along with the "hardwired" classes,
by which I assume you mean getProxyCount() instead of
get("ProxyCount").

But, I understand your concern.

> 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.

I guess, at a high level, adding a config property is an API change,
minor rather than major, though.

> 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 think so.

> 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.

Agree.

In general, my response is to nod my head, meaning I understand and
agree but lack useful feedback.

If we add a property to fix a bug, then incrementing a minor version
seems appropriate

My comments aside, I am pretty sure I will be okay with whatever you
decide, I do not have the experience you do.