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