[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-dev
Subject:    NameID implementation ~ done
From:       "Cantor, Scott" <cantor.2 () osu ! edu>
Date:       2014-03-26 16:50:37
Message-ID: CF587D9B.4BFCA%cantor.2 () osu ! edu
[Download RAW message or body]

Other than wiring more examples in and improving configuration, I think I
finally hit bottom on this, at least where replicating existing
functionality is concerned. I think the only open issue here is the
reloadability of the new configuration, which I mentioned on a previous
call.

I reviewed Spring and I agree now that they really don't provide any
rational notion of reloadability, which is why I don't think DI is
actually as superior as some like to think it is, but that's as may be. So
I'm not sure where to go now.

Today, the configuration of NameID handling is reloadable, albeit spread
across 3-4 different touchpoints. What Rod and I just built is all Spring,
so it wouldn't reload.

Defining a service interface for this is not going to be particularly
elegant, because it's more along the lines of a pile of related components
than a coherent "thing" to invoke. But they're beans at the end of the
day, so one can always just wrap them in a lock/unlock API to get them, it
just won't be particularly coherent as compared to the other services we
have. Probably more akin to how the security APIs may end up looking.

-- Scott


--
To unsubscribe from this list send an email to dev-unsubscribe@shibboleth.net
[prev in list] [next in list] [prev in thread] [next in thread]