KLL as a cross-platform API

[lxs@mac.com]

On Apr 20, 2004, at 2:41 PM, Sam Hartman wrote:

>>>>>> "Miro" == Miro Jurisic <meeroh at meeroh.org> writes:
>
>>> - All these functions need a KLL context argument.
>     Miro> What problem are you trying to solve with the "add a context
>     Miro> argument to all APIs" silver bullet?
>
> Extensibility and thread safety.  I believe we've already decided to
> do so.
>
> Alexis has decided that krb5 was wrong to require every function to
> take a context; functions that take objects already having contexts
> will not take contexts.

To clarify, the new KLL API will be more like the CCAPI in terms of its 
context handling.  In the CCAPI, you create a context for the API and 
then you create types using that context and manipulate the types 
without further needing the context.

Since all KLL types are opaque except for strings, the types will 
contain internal copies of any necessary context information.  As a 
result, the developer won't be forced to pass the context around 
everywhere with the types, and they won't be tempted to pass NULL for 
the context in places where it isn't used by the implementation.

The types will be as object-like as I can make them.  The KLPrincipal 
and KLLoginOptions types are a good example of object-like opaque types 
and should be relatively easy to make thread-safe.  The favorite realms 
list part of the API is a good example of part of the API which is 
neither object-like nor possible to make thread safe.

Using an object-like API design also has the added advantage that it is 
easy to write a well-designed object oriented shim around the library.


--lxs
-----------------------------------------------------------------------
Alexandra Ellwood                                           lxs at mit.edu
MIT Information Services & Technology           http://mit.edu/lxs/www/
-----------------------------------------------------------------------