KLL as a cross-platform API

Jeffrey Altman jaltman at columbia.edu
Tue Apr 6 16:00:55 EDT 2004

Sam Hartman wrote:

>			       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?
I do not believe this is an issue for Windows programmers.
The Windows API uses capitalized words throughout its

>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?
I do not believe this is an issue either.  If we are
at all concerned about confusion we can provide
macros to map Destroy to Dispose.

>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?
This may be a problem if we expect KLL to be used on
smaller platforms such as PalmOS 4

>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.
As long as the KLL supports the krb5_ccache
prefix there should be enough flexibility to support
all of the ccache types.  KFW will desire the ability
to select the MSLSA: krb5_ccache as the source of the
current principal.

>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.  

More information about the krbdev mailing list