KLL as a cross-platform API

[Alexandra Ellwood]

On Apr 22, 2004, at 7:04 PM, Jeffrey Altman wrote:

> I do not think that we disagree at all.  If the programmer
> provides objects and gets what appears to be a random
> result because one of the two contexts is used, I am simply
> stating that the reason for the strange result is the fault
> of the programmer, not the fault of the library.
>
> I don't think the library should be validating the
> equivalence of all contexts passed into a function.

Really this boils down to a problem we already have.

For instance, if you create a krb5_principal pA with krb5_context A and 
a krb5_principal pB with krb5_context B and then call 
krb5_principal_compare(), which context do you pass in?  The answer in 
this particular example is that in the modern krb5 library it doesn't 
matter.

In the model I'm thinking of, the dominant object is defined to be 
always the first one (ie: the object whose "compare me to" method 
you're calling).  So, the KLL comparison function might look like 
KLPrincipalCompare (pA, pB) where the first argument (pA) is the 
dominant object, and its internal context would be favored over the 
second object's internal context whenever it has to pick between them.

As an added benefit, because the contexts are embedded in the opaque 
types, the KLL model has access to both contexts, not just the one the 
caller picked to be dominant.  If it needs to, the comparison function 
can touch a resource in the contexts of both objects (such as thread 
read locks).


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