Alternative proposal (was Plugin project proposal)

[Greg Hudson]

On Wed, 2010-07-21 at 13:44 -0400, Nicolas Williams wrote:
> Here's my sketch for something close to a generic plugin framework that
> can be instantiated for different plugin types, in C.  This design
> obtains strong type safety in both, the application and the plugin code.

I want to acknowledge the effort you put in here and give some context
about our internal decision process, which I realize has been dragging
on.

We spent several hours at our internal meeting yesterday discussing
design choices for the plugin architecture, taking into account list
feedback on all of the individual topics that have been discussed
(dynamic module discovery, plugin provider ABI, etc.).  Thomas is
working on the writeup for this candidate design.

In the meantime, I wrote proof of concept code and checked it into
svn://anonsvn.mit.edu/krb5/branches/plugins2.  People are welcome to
look at that if they want (there's a README.BRANCH at the top level
walking through the code changes), or they can wait for Thomas to finish
the design writeup.

I also read your sketch carefully.  The main significant aspect I noted
is that you use macros to auto-generate the declarations and what we
would call the "consumer API" for each pluggable interface.  That's
laudable in the sense of minimizing how much raw code needs to be
written for each pluggable interface, but as a matter of development
culture, I think we want to move away from using complicated macros to
create code, even if it sometimes means writing more code which looks
similar to other code (and certainly more code than you're write in a
language with higher-order constructs).

My own reason for this preference, which I've already briefly mentioned,
is ease of debugging.  If something goes wrong anywhere near a piece of
automatically generated code, it can be hard to step through it and
understand what's going on if you don't work with that code regularly.
The generated code itself may be 100% correct, but maybe you're passing
it invalid arguments which causes a crash, or maybe the generated code
is invoking other code in which something goes wrong.

Not every code generation mechanism is equally harmful in this respect.
I find macros to be the worst offenders, since the generated code does
not exist in any file unless the developer goes through extra effort to
save the preprocessor output, and even after that the output is
typically very hard to read.  On the other end of the spectrum, code
generated by rpcgen is (1) typically present in the build tree, if you
have a build tree handy, and (2) pretty easy to read.  In the middle are
tools like yacc, which (of necessity) create code which is pretty hard
to understand, but at least it's there in the build tree.

Regardless, every code generation mechanism carries with it its own
complexity, even if it generates really nice easily debuggable code.  I
often believe that it's best to just give up on a little bit of DRY and
call that a cost of doing business for having C as your implementation
language.