Profile config strategy

[Cantor, Scott]

On 12/14/13, 5:30 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

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

Well, my assumption was that we would have code in the -api package(s)
that actually needed to access those interfaces/classes.

Now that you mention it, maybe that's an assumption. If it turns out that
there aren't, or at least that the major ones don't, then this sort of
answers itself, and some of the config classes might become -impl and are
not part of the API, which then eliminates the versioning requirement to
tweak them.

So probably this argues that we just get on with design and sketching out
actions and then see what we have.

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

That's not really a problem, I think. For a native Spring config file,
there's a reference to the actual implementation class, and that's going
to have setters. That's all done indirectly with reflection already.

>Finally, I note that the config class hierarchy goes:
>
>SAML2mumble extends SAMLmumble extends BasicMumble

That's what bugs me. It looks like the deep class trees we got rid of in
the profile context half.

-- Scott