[15929] in Kerberos_V5_Development
Re: design choices for a loadable module interface
daemon@ATHENA.MIT.EDU (ghudson@mit.edu)
Tue Jun 29 16:57:04 2010
Date: Tue, 29 Jun 2010 16:56:58 -0400 (EDT)
From: ghudson@mit.edu
Message-Id: <201006292056.o5TKuwhO013320@outgoing.mit.edu>
To: krbdev@mit.edu
In-Reply-To: <20100525225623.GN9605@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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).
Some arguments in favor of each shape:
* Plan Nico requires the least amount of code for a dynamic plugin
implemention.
* Plan Nico allows you to add new methods while retaining
compatibility with old plugins, as long as the new methods are
optional.
* Plan Simo potentially requires zero changes to the implementation
source code to make it built into the consumer rather than
dynamically loaded. This is interesting for deployments with
no-shared-library requirements, and possibly also for portability to
Windows.
* If there are incompatible changes to a pluggable API across versions
of Kerberos (not just adding new optional methods), Plan Simo makes
it possible, though perhaps difficult, to provide a shared object
which works with multiple Kerberos versions. This is most
interesting for the DAL, where we have no stability guarantees and
know we want to make lots of big changes.
* Plan Simo makes it potentially easier to set breakpoints at specific
method implementations. This is a pretty minor point, as there are
good workarounds.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
