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
eliminated.
meeroh
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
Layouts.
--
<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