kdb ldap back end

[Praveenkumar Sahukar]

Hi,

My comments start with ">>".

I'm (finally!) getting a chance to start digging into the LDAP back  
end.  One issue has jumped out at me:  On some systems, dynamically  
loadable objects and shared libraries are not the same.  So for  
portability, we'll assume the system can support loading an object  
with dlopen (or other system- specific means), or linking against it  
as a shared library, but not both.

The ldap- util program links against the ldap database plugin,  
currently.  I think the best fix is probably to split off most of the 

plugin into a separate shared library that both the ldap- util program 

and the database plugin are linked against.  But that brings up the  
question of how much should move and how much stay in the plugin, and 

what should be exported from the new library.  (Are we ready to  
consider it a published interface that we'll maintain binary  
compatibility with going forward?  My guess is no, so we can do  
whatever we want now and change it as needed later.)

>> A separate library can be derived out of the ldap database plug-in.

>> My guess is, with the separate library, ldap-util program need not
link to the ldap database plug-in. am i right ? 
>> If yes, even with a separate library ldap-util will have to link to
the plug-in as the ldap-util is 
>> making use of DAL apis for LDAP (like krb5_ldap_put_principal) and
these functions 
>> will have to stay in the plug-in as they are needed by DAL.

>> We can write some wrapper routines that in turn will call DAL apis
for LDAP (like krb5_ldap_put_principal).
>> The wrapper functions will become part of the plug-in and will be
called by DAL.
>> The DAL apis (like krb5_ldap_put_principal) can be moved to the
separate library
>> and ldap-util can call the DAL apis directly. This way ldap-util
will not have to link to plug-in.

The alternative approach is probably to have the ldap- util program  
dlopen the database module and go looking for the functions it wants  
to call; I don't like that approach as much, myself, though it does  
let us sidestep the shared- library questions for now.

>> I agree with this point. 

Regards,
Praveen Kumar