KLL as a cross-platform API

Miro Jurisic meeroh at meeroh.org
Tue Apr 6 17:26:40 EDT 2004

To provide a little background, it was always my intent that the KL 
API could be implemented on other platforms when the time was ripe 
for such an endeavor; however, it was clear to me when I wrote the 
original implementation that large parts of the implementation would 
not be portable, and that the API itself would probably not be 
portable without at least one significant revision, because I neither 
had the knowledge of other platforms needed to fully appreciate the 
impact of some of the design decisions, nor the time to educate 
myself before proceeding.

As your comments indicate, some of those decisions are a cause of 
concern when considering the KL API for porting. I completely agree.

Kerberos Login API is over five years old; if you are looking at a 
major event in the lifetime of the library (and being ported to other 
platforms is certainly a major event), I think that's a great 
opportunity to review it carefully and clean up any warts the API may 
have acquired over the five years.

I think that KL API should be viewed as a Mac-specific stepping stone 
towards a cross-platform login API. In my opinion, the primary value 
of the KLL is in the knowledge gained by creating the implementation 
that interoperates with GSSAPI and krb4 (which is, of course, less 
important now). This knowledge largely resides with lxs and her KLL 
code, as she did most of the GSSAPI integration work over the years.

Because you are considering adding KL API to the cross-platform 
Kerberos package, my recommendation would be to sit down with the 
concerns you voiced over the existing KL API and spec a new API that 
eliminates all those concerns, provides a consistent API 
look-and-feel with the krb5 and GSS APIs, and doesn't have Mac bits 
sticking out in various places. Bless this new API, and expose KL API 
as a simple wrapper around the new API for Mac OS applications that 
still need it.

This would also be an opportunity to consider which of the KL 
abstractions are duplicates of abstractions from krb5, and exist 
primarily because KLL was an isolated entity -- e.g., krb5_princ and 
a KLPrincipal -- and whether any of that duplication can be safely 


PS. One more reason to rename the APIs is that Apple has another API 
that uses the KL prefix, starting with Mac OS X 10.2, though there is 
little chance of confusion between Kerberos Login and Keyboard 

<http://web.meeroh.org/> | KB1FMP

"And when I have understanding of computers, I shall be
         the supreme being!" -- Evil, "Time Bandits"

More information about the krbdev mailing list