[15880] in Kerberos_V5_Development
Re: design choices for a loadable module interface
daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Fri Jun 4 18:41:14 2010
Date: Fri, 04 Jun 2010 18:08:00 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nicolas Williams <Nicolas.Williams@oracle.com>
Message-ID: <C84497D74FC2E8B3C7FF393C@atlantis.pc.cs.cmu.edu>
In-Reply-To: <20100604215118.GX9605@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
Cc: krbdev@mit.edu, Tom Yu <tlyu@mit.edu>, jhutz@cmu.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
--On Friday, June 04, 2010 04:51:18 PM -0500 Nicolas Williams
<Nicolas.Williams@oracle.com> wrote:
> Really, let's hear good reasons to not do the dlsym()-memoized-via-
> internal-vtables (which are then NOT part of the ABI). I can't think of
> any.
Well, it's about what happens when you want a single plugin to provide more
than one thing, like multiple related PA types or a PA type and an AD type
or whatever. As it is, you have specific "types" of extensions, the plugin
framework has to know what the types are and what the interface is to each
type, and you are restricted to each shared object containing exactly one
extension of exactly one type. A register_foo()-style interface eliminates
this tight binding and the corresponding abstraction violation (*). Of
course, the price is all of the problems you mentioned.
Once the design decision has been made that one-extension-per-shared-object
is acceptable, memoized-dlsym() definitely seems like the right answer.
(*) Of course, there are other ways to abstract knowledge of each plugin
ABI away from the plugin framework.
-- Jeff
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
