[15987] in Kerberos_V5_Development
Re: Plugin project proposal
daemon@ATHENA.MIT.EDU (Simo Sorce)
Thu Jul 15 15:02:49 2010
Date: Thu, 15 Jul 2010 15:02:42 -0400
From: Simo Sorce <ssorce@redhat.com>
To: Zhanna Tsitkova <tsitkova@mit.edu>
Message-ID: <20100715150242.7b110dd0@willson.li.ssimo.org>
In-Reply-To: <A69DE956-8C53-42C9-AD42-1F54C352E720@mit.edu>
Mime-Version: 1.0
Cc: Russ Allbery <rra@stanford.edu>, krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Thu, 15 Jul 2010 14:25:25 -0400
Zhanna Tsitkova <tsitkova@MIT.EDU> wrote:
>
> On Jul 15, 2010, at 1:14 PM, Russ Allbery wrote:
>
> >>
> >> 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.
>
> Suppose we have defined an interface for plugin_A.
> At later time one may want to extend the interface of this plugin.
> Now, can these two versions coexist? Yes, and one of the possible
> solutions is to implement v-tables as hashes.
> In this case the interface consumer can check for the availability
> of the new method by querying the hash-table. If "new method" is
> not implemented, it returns null pointer. And one can decide how to
> proceed further.
if (vtable->new_method == NULL) { /* not implemented */
Simo.
--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
