[1811] in Kerberos_V5_Development
Re: Krb5 Ccache DLL proposal
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Fri Sep 27 11:54:55 1996
Date: Fri, 27 Sep 1996 11:54:24 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Marc Horowitz <marc@MIT.EDU>
Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, mikec@geek.grf.ov.com,
harryc@cam.ov.com, pbh@MIT.EDU, krbdev@MIT.EDU, dosdev@MIT.EDU
In-Reply-To: Marc Horowitz's message of Thu, 26 Sep 1996 20:40:35 EDT,
<199609270040.UAA20517@beeblebrox.MIT.EDU>
Cc: mikec@geek.grf.ov.com, harryc@cam.ov.com, pbh@MIT.EDU, krbdev@MIT.EDU,
dosdev@MIT.EDU
Date: Thu, 26 Sep 1996 20:40:35 EDT
This API seems to overlap substantially with another one provided by
krb5 already, namely the krb5_cc_*() set of functions. Now, the
current implementation of these functions is actually as macros, and
they are not exported in any DLL right now, but both these issues
could easily be addressed.
The idea is that the krb5_cc_* set of functions will call the DLL
interface functions.
I have heard some people say the current ccache functions aren't very
clean, and could be troublesome to convert to a DLL. In this case, we
could call the new API the only ccache API, deprecating the current
one, and that would be fine with me. I just don't want to see us
supporting two APIs to do the same thing.
Yes; the idea is to make it easy for people to actually implement the
DLL, so that people will actually accept our proposal. Remember, the
audience of this proposal are not all necessarily vendors who are using
the MIT Krb5 code base.
We could convert our API to something which much more easily matches
this one. Unfortunately, we have already made commitments to people
(such as the X consortium, for example) that we wouldn't be making any
more changes to the Krb5 library API.
We could support two variations of the ccache API in the MIT Krb5
library, but that would be adding even more complexity.
The best solution is for us to have a translation layer which the
implements current set of function pointers expected by our current
krb5_cc_* functions, and have that layer call DLL cache. That layer is
going to have to dynamically pull in the DLL anyway, so it's going to
have some messy code in it anyway.
- Ted
