Reverse attribute mapping..

[Tom Zeller]

>>Is the proposal to rename net.shibboleth.idp.Attribute to
>>net.shibboleth.idp.IdPAttribute ?
>
> Yes. The code's very hard to follow when Attribute shows up on both sides
> of the abstraction.

I must be missing something. From what I can tell, the proposal is to
rename net.shibboleth.idp.Attribute to net.shibboleth.idp.IdPAttribute
so that org.opensaml.saml.saml2.core.Attribute does not have to be
fully qualified. Am I correct ?

> InternalAttribute would work, but it's longer and connotes something that
> wouldn't be expected to be an actual API. We already have IdPSession
> (though I considered changing that to Session, and decided not to), so
> it's consistent.

Again, y'all are too smart for me to be saying this, so I must be
dense, but there are multiple kinds of sessions in the IdP, so
IdPSession and SPSession or ServiceSession further qualify the kind of
session. There are only a handful of classes in the v3 IdP which start
with "IdP", IdPSession and IdpInitiatedSsoRequest*, so I do not
understand what you mean by consistent.

Now that I know what we are talking about ...

> Anyone objections to this?  It strikes me that this will be a wide ranging
> checkin so it might serve as a test for the capitalization change process.
> Why don't I try this: Once I have the change ready I'll give people a 24
> hour heads-up to check-in any things they have - or to veto my check-in. To
> be honest I think that this might be overegging things - this sort of change
> is likely to merge up just dandy.

Yes, I object.

I object to the proposed refactoring as well as the 24-hour veto.

I think that changes to the IdPv3 APIs, even as unreleased, should get
a new email thread or JIRA issue and time for me to think about it.

If the reason for the refactoring is solely improved readability of
the attribute mapper, then I suggest that the refactoring is
inappropriate for the perceived benefit, which is subjective.