Custom metadata provider
Brent Putman
putmanb at georgetown.edu
Wed Dec 9 20:43:09 EST 2015
On 12/9/15 8:13 PM, Cantor, Scott wrote:
> On 12/9/15, 7:59 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
>
>
>
>> I thought the whole concern here was that external projects consuming OpenSAML *must* depend on stuff in the -impl modules, since that's where all the good stuff and actual functionality is located. (excepting the XMLObject provider stuff which already has the registry indirection layer). But that's notionally an unrealistic burden and requirement, because the -impls are unstable and can change in breaking ways. Ergo there's a problem: They have to depend on unstable stuff, practically no way to avoid.
> Ok. I think our contract there is clear, whether it's good for anybody or not.
I agree, I think it's currently *clear*. Just not good, for the
external projects.
>
> But there *are* interfaces and base classes that I think we could commit to but haven't yet. Meaning, yes, it's still not a real answer, but where we do have things we can move into the API, we should try and do that.
Again I agree. But all of those we could move are probably about a 5%
percent improvement. All the good concrete stuff (read: usually hard
stuff to implement) is going to stay impl. And people are not likely
to implement their own trust engines, message
encoders/decoders/handlers, profile actions and probably a zillion
other things, just to avoid this. They're going to use our impls, and
so they're going to be dependent on unstable code. (Or else we do as
we implicitly have been, acknowledge this situation, and defacto treat
those as API, and don't make breaking changes outside of a major
version. We technically *can*, but practically speaking we don't.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20151209/0746c429/attachment.html>
More information about the dev
mailing list