Plugin project proposal

[Russ Allbery]

Zhanna Tsitkova <tsitkova at MIT.EDU> writes:

> 2.  2. It was suggested to use hash tables for the plugin interfaces in
> lieu of C structures. This would provide better plugin impl. version
> control and interface extensibility.

I'm not sure what you mean by hash tables here.

> 3.  3. Another interesting suggestion is for plugin interface to be more
> generic and follow a request-response paradigm:

>         generic_collection *request, *response;.

>         ....

>        plugin_manager_get_service(ctx->pl_manager, PWD_QLTY,  
> PWD_QLTY_KRB, &plugin_handle);

>       /* Funtion to pack local parameters into a collection object */

>        create_request_object(&request, srv_handle, password,  
> use_policy, pol, principal);

>        plugin_manager_execute(plugin_handle, request, &response);

>        destroy_collection(request);

>        destroy_collection(response);

>        /* Now when we go a generic response object that consists of  
> the key value pairs we can process it and see if it returned enough  
> information for us to continue */

>        error = get_error(&error, response);

Ugh, no, please don't do this.  This makes the code more opaque and
tedious to write, which is already a problem with the current
implementation.

I think a major goal of the plugin architecture should be to try to make
the code internals more transparent and obvious.  One of the things that I
struggle with right now in the MIT Kerberos code base is that it can be
extremely difficult to trace through code and figure out where things are
actually being done.  Adding additional levels of generic redirection like
this on top of what's already happening will make that problem worse.

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