Plugin project proposal

Nicolas Williams Nicolas.Williams at oracle.com
Thu Jul 15 13:21:52 EDT 2010


On Thu, Jul 15, 2010 at 10:14:39AM -0700, Russ Allbery wrote:
> 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.

I don't follow that either.

> > 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.

+1

I don't understand why do something like the above either.

I'm generally opposed to re-implementing or unnecessarily wrapping
things that compilers, linkers, etcetera already do.  In this case we'd
be wrapping function call and argument passing, and I see nothing to be
gained for it here.

Nico
-- 



More information about the krbdev mailing list