Alexandra Ellwood wrote:

On Jan 25, 2008, at 10:45 AM, Jeffrey Altman wrote:

Kevin Koch wrote:
I've updated the Windows CCAPI design sketch, hopefully answering previous
questions.
The document has moved again and is now at
http://k5wiki.kerberos.org/wiki/Projects/Windows_CCAPI.

For those who are interested, the source code has been checked in to
.../krb5/src/ccapi/*/win.

Comments are welcome.

Thanks.


Kevin:

Could you please add sections describing:
* the platforms that are being supported
* the development tools that are being supported

Don't know anything about these Windows issues.
I wasn't expecting you to be the one responsible for answering them.


* a summary of the differences in functionality between the currently deployed CCAPI and this one. In particular, what are the known compatibility issues that application developers are going to have to deal with when the transition occurs.



Cross-platform changes:


CCAPI v2 is deprecated. All CCAPI v2 functions return errors when called.
This decision is going to cause problems for all currently deployed applications which support the use of multiple credential caches. These applications use the CCAPIv2 to enumerate the available credential caches in order to determine which caches are available. There has been no other interface for them to use. By failing to implement CCAPIv2 on top of the new implementation there will be no transition mechanism for organizations to use when upgrading to KFW 4.0 and CCAPIv7.


Locking functions (cc_context_lock, cc_context_unlock, cc_ccache_lock and cc_ccache_unlock) now work. Locks are advisory so existing callers should see no change in behavior if they were not using the locking functions. Obviously if code was using the locking functions previously (in the previous implementation they just functioned as NOPs) then the caller might see different behavior switching to the new CCAPI.

Two new functions: cc_context_wait_for_change() and cc_ccache_wait_for_change() which block until the next change to the cache collection or ccache respectively. These function allow multithreaded applications to avoid polling when trying to update on changes. They are intended to replace the "change time" functions.

In order to allow applications to test for these new features the API version number has been bumped to CCAPI version 7.

Any other difference in the behavior of the new and old CCAPI implementations is a bug and should be filed in our bug tracking system.
These are changes to the CCAPI for versions that were never deployed on Windows. Therefore, I do not consider them applicable to the discussion of the Windows implementation. The questions that need to be answered are those that application developers and system administrators are going to use to determine how and when KFW 4.0 can be deployed


Jeffrey Altman

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
kfwdev mailing list
kfwdev@mit.edu
http://mailman.mit.edu/mailman/listinfo/kfwdev

Reply via email to