+1 for introducing the changes. Moving the project forward requires not only adding new features but also making sure the API can handle future use cases.
If the only thing blocking these changes from going in is that we picked a label of "3.5", then just pick a new label that supports these APIs. Marvin's done a lot of work with this, and I've previously done a lot of work with APIs, and I keep seeing of these being pushed aside as being out of scope. These APIs have come out of attempting to solve real world problems with existing APIs and code. Delaying them even further hurts the project. Cheers, Scott On Tue, Jan 31, 2012 at 2:40 PM, Marvin Addison <[email protected]>wrote: > > I appreciate the alternative work that Marvin put forth and agree with > > the goal of supporting password expiration with a broader view than > > just LDAP. > > That's good to hear. > > > However, the proposed alternative is too sweeping a change > > for 3.5 based on the release strategy. > > That's too bad, but it's easy to admit that it was a stretch. My > motivation for this work relied on leveraging the needs and interest > for LDAP password expiration to drive some big API changes. I'm > concerned that the API changes that I've sketched out will _never_ > happen without some strong driving force, and that will be a big loss. > > M > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
