[15935] in Kerberos_V5_Development
Re: design choices for a loadable module interface
daemon@ATHENA.MIT.EDU (Russ Allbery)
Tue Jun 29 18:19:30 2010
From: Russ Allbery <rra@stanford.edu>
To: krbdev@mit.edu
In-Reply-To: <20100629221226.GB11785@oracle.com> (Nicolas Williams's message
of "Tue, 29 Jun 2010 17:12:26 -0500")
Date: Tue, 29 Jun 2010 15:19:25 -0700
Message-ID: <87lj9xfpn6.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Nicolas Williams <Nicolas.Williams@oracle.com> writes:
> That just means that all plugins export functions with the same names,
> as opposed to having to prefix each plugin's exported functions' names
> with a disambiguator, such as the plugin's name.
Oh, okay. I certainly agree with that.
> HOWEVER, just because there is one thing that the linker/loader will not
> do for us does not mean we should throw the baby out with the bath water
> and effectively duplicate other linker/loader functionality.
Could you be more specific about exactly what functionality you see the
vtable approach as duplicating? I assume you mean something more than
just writing the struct definition of the vtable, since that's trivial.
>> With either the vtable or the function approach, you have to rename the
>> symbols whenever the signature changes. With the vtable approach, you
> Not so. You can deprecate old ones and add new ones. No renames
> needed.
That's what I meant by "rename." That's what I assumed we would do in a
rename. The point is that the current recommended API uses a different
name than the previous one so that backward-incompatible changes can be
made.
> If you decide to never make backwards-incompatible changes to function
> signatures and semantics then you there is no need to keep track of
> anything more with one scheme or the other.
I believe the chances of successfully holding to such a decision are zero.
There will be backwards-incompatible changes to function signatures and
semantics. The framework should plan for them from the start.
> (1) and (2) really are equivalent, except that (2) requires more work on
> the part of plugin authors than (1).
Speaking as a plugin author, the amount of additional work (2) requires is
not sufficient to warrant calling it additional work (although of course
just providing a public data symbol is even easier). It's a trivial
function that one can write in five minutes.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
