StoredID Canonicalization, DataSources, configuration & code structure

Cantor, Scott cantor.2 at osu.edu
Fri Jan 31 10:49:23 EST 2014


On 1/31/14, 4:58 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:

>> > to clarify, I don't think we should have any
>> > dependency on any saml modules in the resolver at this point, as a
>>goal.
>> > And we're probably not far from that.
>
>And just to confirm (because my brain is melting) you mean this at the
>api-level
>
>	attribute-resolver- api SHOULD not depend on saml-api
>	*-impl MUST not depend on *-impl
>
>There has to be a dependency between resolver-impl and saml-api (or
>between
>saml-impl and resolver-api) since they implement two side of the same
>story
>(transients).

Sorry for jumping the gun, but let me clarify...I mean that ideally all
the SAML-specific interfaces for plugins in resolver-api should be in
saml-api, and ideally all the SAML-specific implementations would be in
saml-impl.

That would require saml-impl to depend on resolver-api, yes, because it
would be supplying resolver plugins.

Should we do that right now? Probably not. But since I thought the primary
cases were the transient/persistent code, the opportunity might present
itself to just do the new versions in the right modules. If not, we can
ignore the issue until a future version, or move them after they're done.

Basically, I'm trying to validate the design by ensuring there are no
SAML-isms in any modules but the saml ones.

-- Scott




More information about the dev mailing list