Password sync plugin, and questions about plugin criticality

Nicolas Williams Nicolas.Williams at sun.com
Tue Jun 27 15:49:15 EDT 2006


On Tue, Jun 27, 2006 at 02:17:34PM -0400, Sam Hartman wrote:
> Although Luke is right.  Parameter bloks (allocated by the party that
> is most likely to want to extend functionality) are the right thing to
> do when you want extensible interfaces.  for example, the
> krb5_get_init_creds extensibility was a good approach except that the
> caller allocates the paramater block  and so it cannot be extended.

Make the relevant type opaque too, so neither its layout nor size are
relevant to the party that doesn't get to extend it, and provide
accessor functions.

PAM, again, is a good example of such an API.  Posix_spawn is almost a
good example also.

krb5_get_init_creds_opt_*() is almost a good example also, except that
the options type is visible to the application and allocated by it also.
(But if its contents are not part of the API nor intended to be part of
the ABI then you could get a lot of extensibility out of
krb5_get_init_creds_opt_*()...)

Nico
-- 



More information about the krbdev mailing list