Password sync plugin, and questions about plugin criticality

[Nicolas Williams]

On Mon, Jun 26, 2006 at 04:00:36PM +1000, Luke Howard wrote:
> That said, I don't mind the approach Netscape took with the SLAPI
> plugin API for their directory server (Sun, OpenLDAP, IBM all use
> the same interface). If we are looking for a plugin API we can
> generalize to other interfaces and is extensible without breaking
> ABI compatability, something similar might we worth looking into.
> 
> In this case it might look something like:
> 
> /* kapi-plugin.h */
> typedef struct kapi_pblock Kapi_PBlock;
> int kapi_pblock_get(Kapi_PBlock *, int, void *);
> int kapi_pblock_set(Kapi_PBlock *, int, void *);

In the cases of simple SPIs I much prefer that the mechanism export its
entry points directly and that the framework dlsym() them.  This pretty
much works on all platforms that MIT needs to support where the SLAPI
model would also work, and it makes plug-in code simpler.

> (The name of the initialization function would be specified in the
> configuration.)

Is the idea to avoid symbol name conflicts?  This should only be needed
where there's no reasonably modern dynamic linker.  And then other
build-system techniques should do (namely, rename the entry points on a
per-plug-in basis to unique names at build-time and static link
everything).

Where there are modern dynamic linkers whatever the moral equivalent of
RTLD_LOCAL is should suffice (plus RTLD_GROUP, to be rigorous).

Nico
--