Plugin project proposal

[Russ Allbery]

Simo Sorce <ssorce at redhat.com> writes:
> Zhanna Tsitkova <tsitkova at MIT.EDU> wrote:

>> Suppose we have defined an interface for plugin_A.
>> At later time one may want to extend  the interface of this plugin.
>> Now, can these two versions coexist? Yes, and one of the possible  
>> solutions is to implement v-tables as hashes.
>> In this case the interface consumer can check for the availability
>> of the new method by querying  the hash-table. If "new method" is
>> not implemented, it returns null pointer. And one can decide how to  
>> proceed further.

> if (vtable->new_method == NULL) { /* not implemented */

This would require modifying old modules when you add a new function to
the interface, so probably isn't feasible.  This is the big drawback to
vtables.  Each time you change the interface, including when adding new
functions, you need to export a different symbol from newer plugins with a
different vtable that includes the new slot, and then the loading logic
needs to check which version of the plugin API is supported.  Either that,
or you need to return the vtable from a function.

This is where the proposal to just use straight exported functions is a
lot simpler.  If the common operation is to add new functions, that's the
better design.

If the more common operation is to change function signatures, the vtable
design is moderately easier to deal with, IMO, although I can see how
that could be debatable.

I'm not sure we know which is likely to be the most common operation.  My
guess is actually that we'll have very static interfaces that will
accumulate desired changes and then periodically undergo complete
revision, which is why I like the vtable approach because it's probably
the cleanest for handling that sort of situation.

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