design choices for a loadable module interface

[Russ Allbery]

ghudson at MIT.EDU writes:

> Based on some internal discussions, I think this conversation needs to
> be continued slightly and summarized.  To simplify the summary, here are
> two concrete ABI design shapes:

> 1. Plan Nico: each dynamic plugin exports one function symbol per
> method.  The names are the same across all plugin implementations of
> an interface.

> 2. Plan Simo: each dynamic plugin exports an init function, whose is
> constructed based on the plugin implementation name (e.g. "db2_kdb_init"
> for the DB2 KDB module, "ldap_kdb_init" for the LDAP KDB module).  The
> init function accepts a version number and outputs a structure full of
> function pointers for the methods (aka vtable).

I prefer plan 2 because I think the ability to provide one module which
supports multiple different Kerberos versions is important, although I'm
not sure why one would use that plan as opposed to just exporting the
vtable as the public symbol and naming the vtable public symbol to include
the ABI.  I rather liked that approach; I thought it worked quite well and
was nicely straightforward.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>