Password sync plugin, and questions about plugin criticality

[Sam Hartman]

>>>>> "Ken" == Ken Hornstein <kenh at cmf.nrl.navy.mil> writes:

    >>> I don't think I follow this; how exactly is this supposed to
    >>> work?  Specifically, I don't understand what kapi_pblock_* is
    >>> doing.
    >>  OK, perhaps an example was the wrong approach. What I was
    >> trying to convey was that can be useful for each entry point to
    >> take a single (or well defined number of) argument(s).
    >> 
    >> One argument would be an opaque "parameter block" or handle;
    >> the SPI would provide appropriate accessor functions.
    >> 
    >> That way both the API and ABI can be maintained as the
    >> interface is extended. It can also make it easier to generalize
    >> the SPI layer for different sorts of plugins.

    Ken> Ah, okay, I understand now.  MIT does that a different way
    Ken> (their plug-in interface does versioning), but they already
    Ken> have functions that take varying number of arguments, so I
    Ken> don't think that's a concern.

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.

Se KLL onn the Mac for an example of how this can be done reasonably.

You should use this approach whenever extending the number of
arguments to functions seems likely.

--Sam