New Function in IdP V3.4/V4
Rod Widdowson
rdw at steadingsoftware.com
Wed Jul 19 13:34:37 EDT 2017
Again, possibly a topic for Friday.
I was going over my open IdP cases recently and happened upon IDP-1172[1] and IDP-692[2]. These are wildly difference cases but
open me up to the same dilemma: Do we put new function into 3.4 so that the old stuff can be removed in 4.0?
On the one hand it would be nice to not ship V4 with a list of pre-deprecated functions and configuration, but on the other hand V4
is supposed to the new function release.
Equally 3.4 is supposed to be a progression and anything new at least theoretically introduces instability (although backwards
compatibility means the risks are limited).
For the record the suggested new functions in these cases are:
1) Support DBCP from native configuration syntax/deprecate V3P0
2) New shell refresh Resource to replace SVN based Resources (and to open the door to git). Deprecate SVN
3) Security custom namespace:
a. Provide a workable option to the current mainline uses (mostly keys to LDAP).
b. Look at configurability of the edge cases, possibly introducing true mixed mode (native spring/custom schema) parsing.
c. Deprecate the sec: namespace
But I imagine that there are other cases in other areas which have a similar issue.
For completeness I should also mention that I think that there are some changes which are large enough to be better deferred into V4
in their entirety. It would be very likely that the magnitude of config changes these implied would mean that we would not require
immediate deprecation of the old style function (think old style relying-party.xml).
The example which springs to mind here is replacing AttributeEncoder statements with a separate data dictionary. This is a pretty
monumental change and there is no way that we wouldnt want to support both styles for a while.
Nonetheless there might be an argument to be made for at least having the design mapped out prior to 3.4 in case it requires some
configuration underpinnings changed prior to V4.
Thoughts?
[1] https://issues.shibboleth.net/jira/browse/IDP-1172
[2] https://issues.shibboleth.net/jira/browse/IDP-692
More information about the dev
mailing list