[15983] in Kerberos_V5_Development
Re: Plugin project proposal
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Thu Jul 15 13:23:32 2010
Date: Thu, 15 Jul 2010 12:21:52 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Russ Allbery <rra@stanford.edu>
Message-ID: <20100715172151.GE22556@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <87hbk0vf9c.fsf@windlord.stanford.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Thu, Jul 15, 2010 at 10:14:39AM -0700, Russ Allbery wrote:
> Zhanna Tsitkova <tsitkova@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
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
