I am working on a CCAPI v2 shim layer for the new CCAPI. Should have it ready for testing by the end of the week.
On Feb 6, 2008, at 2:05 PM, Jeffrey Altman wrote: > NIM2 is not dependent upon 1.7. However, given the recent > discussions of > the new credential cache not supporting CCAPIv2 there will be a > break in > functionality of NIM and NIM2 if the new CCAPI is deployed without > re-writing > the NIM Kerberos v5 provider. (Also note that the KFW klist.exe is > also > dependent upon CCAPIv2.) > > As long as the 1.7 libraries do not break backward compatibility, > there is > no issue for NIM2 (and other applications that depend on MIT > Kerberos.) > If there is a break in backward compatibility, it will be harder to > deploy > a new krb5 NIM provider that supports both the old and the new > libraries. > > Jeffrey Altman > Secure Endpoints Inc. > > > Kevin Koch wrote: >> Jeff -- >> >> Considering the later discussion of NIM2 being independent of the >> Kerberos >> 1.7 libraries, is 1.7 a non-issue for NIM2? >> >> Thanks. >> >> Kevin >>> -----Original Message----- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >>> Behalf Of >>> Sam Hartman >>> Sent: Monday, November 12, 2007 5:43 PM >>> To: kfwdev@mit.edu >>> Subject: KFW releases off the trunk will become harder as 1.7 >>> features >>> startgetting used >>> >>> One long-running aspect of our release process is that the trunk is >>> allowed to take advantage of features on the trunk. In particular >>> this means things like as we get new implementations of CCAPI, KIM >>> and >>> other APIs available, we'll want to start using them. And we don't >>> generally support backward compatibility for this sort of change. >>> >>> One consequence of this is that we may start running into cases >>> where >>> specific changes to KFW will end up depending on the 1.7 release or >>> at least the 1.7 release branch. I'd expect to get to a point in a >>> few months where any significant changes to KFW would depend on 1.7. >>> >>> We've been traditionally very reluctant to pull significant features >>> for future releases back to old release branches. I'd expect Tom to >>> continue that practice. We may develop more well defined guidelines >>> for when pull-ups are appropriate, but I would expect anything we >>> came >>> to consensus on to be relatively conservative in this regard. >>> >>> There may be projects that we want to consider and try and avoid >>> blocking behind 1.7. I think that quite soon, we're going to want >>> to >>> establish a deadline for any such project to be proposed and for >>> us to >>> at least have the community discussion about whether we want to >>> avoid >>> blocking the projects behind 1.7. >>> >>> Kevin, I'd appreciate it if you could work with Jeff and anyone else >>> who has an opinion and decide on a deadline by which projects that >>> want to avoid being blocked behind 1.7 must be proposed. >>> >>> I think that shorter than two weeks from today would be unrealistic. >>> I think that a deadline beyond Jan 15 would probably be too long. >>> >>> >>> One specific concern I have is the NIM 2.0 work. There was a >>> project >>> proposal over the summer for the user experience. However there >>> hasn't been any proposals made regarding technical impact or how the >>> user experience would be accomplished. >>> >>> That's fine, but until such proposals are reviewed, we as a group >>> won't be in a position to avoid taking NIM 2.0 design into account >>> and >>> avoid making things harder for NIM 2.0. >>> >>> Thanks for your consideration >>> >>> --Sam >> ... >> >> _______________________________________________ >> kfwdev mailing list >> kfwdev@mit.edu >> http://mailman.mit.edu/mailman/listinfo/kfwdev > _______________________________________________ > kfwdev mailing list > kfwdev@mit.edu > http://mailman.mit.edu/mailman/listinfo/kfwdev --lxs Alexandra Ellwood <[EMAIL PROTECTED]> MIT Kerberos Development Team <http://mit.edu/lxs/www> _______________________________________________ kfwdev mailing list kfwdev@mit.edu http://mailman.mit.edu/mailman/listinfo/kfwdev