KLL as a cross-platform API

[Sam Hartman]

KFM has had an API called the Kerberos Login Library for a while.  It
makes it easy to get credentials and to manipulate these credentials.
It's even documented; take a look at
http://web.mit.edu/macdev/KfM/KerberosFramework/KerberosLogin/Documentation/API.html.


Alexis is working on revisions to this API for the next version of
KFM.  The primary purpose of the revisions is to make KLL thread safe.


Jeffrey Altman wants a future version of KFW to support KLL.  I think
everyone on the team realizes that krb5_get_init_creds is not the
paragon of user-friendly APIs.  I think it is better than
krb5_get_in_tkt, but an even higher level API would be nice for users.


If KLL is going to remain a KFM-specific API then I don't think this
list needs to consider it much.  It is already meeting the needs of
the KFM user community.

However if we are going to have similar APIs for all our platforms to
do this sort of initial credentials management then it should be
consistent across platforms.

Here are my thoughts on KLL as a cross-platform API.  It's not clear
that we have time or desire to implement these comments.  They are
being submitted to start discussion.  One thing that would be
particularly useful to us would be feedback from vendors like Sun,
Redhat and KFW about the suitability of KLL as a cross-platform API.

			       Comments

I suspect the most controversial decision in KLL is its identifier
name style.  IT uses studlycaps rather than lower case with
underscores.  That's desirable for KFM because it is more consistent
with Mac APIs.  However the krb5 and krb4 APIs tend to use
underscores.  How confused will programmers be by having two different
styles of API in the same product?  Would consistency between KLL and
say GSSAPI affect vendors' decisions on whether to support the API?

Similarly, because of the Mac's Pascal roots, functions to get rid of
resources are called Dispose not Free or Destroy.  I don't think this
is a particularly big deal; does anyone?



KLL uses enumerated types for constants.  It does so in a manner
fairly consistent with the direction we are moving for krb5.
Anonymous enumerations are used for constants, but enumeration types
are not part of the ABI.  One thing it does do that the krb5 code does
not currently do is use character constants for option names.  Here's
an example:

enum {
/* Initial values and ranges */
loginOption_LoginName                  = 'name',
loginOption_LoginInstance              = 'inst',

loginOption_ShowOptions                = 'sopt',


IN particular, this requires that the enumeration type be at least as
wide as 4 chars.  Do we think this will ever be a problem?

Currently, KLL only supports API: ccache types.  Alexis said she will
add support for file credential caches in her current work.
Presumably on Windows we'd need support for MSLSA caches at least for
some functions.

KLL seems to have dialogue and event loop support at least for OS9.  I
doubt this will ever be portable across platforms; we probably have to
accept that each platform needs its own event loop code.