Plugin project proposal
tsitkova at MIT.EDU
Thu Jul 15 12:59:01 EDT 2010
Moving the initial Plugin Improvements project proposal to the mailing
thread independent from "design choices for a loadable module
In the second part of this email you will find the desr of the proj
updates and new suggestions.
For the benefit of those who did not have chance to look at the
project site http://k5wiki.kerberos.org/wiki/Projects/Plugin_support_improvements
the proposal is about creating the framework that simplifies
creating and managing plugins.
The main participants in the new architecture are:
Plugin Manager (PM) - its main purpose is to manage plugin
configuration and registration. In addition PM is responsible to
maintain a container populated with plugin handles (references to
plugin objects) and to provide the search capabilities for callers
requesting the plugin services.
Plugin Loader (PL) - Abstract module that declares an interface for
operations that facilitate manipulation with the set of plugin
Plugin Loader Implementation (PLI) - Concrete implementation of PL. It
knows about the set of the available implementations and how to create
Plugin Interface (PI) - Abstract module that declares plugin interface.
Plugin Interface Implementation (PII) - aka Plugin Module - Concrete
implementation of the plugin interface;
Plugin related configuration and registration happen at run time,
during the krb5 context creation. At this time PM registers all
available built-in plugins. (The list of the desired plugin
implementations is known to the specific PLI, which is aggregated
within PM.) It also consults with the configuration file to verify if
all built-in plugins are enabled (administrator can disable an
undesired plugin). In its turn, the information about the dynamic
plugin modules, such as their location and properties, may be obtained
from the configuration file. Again, the dynamic plugin modules are
then registered with PM. PM delegates acquiring of plugin interfaces
From now on, to invoke the desired plugin interface, the caller
obtains the plugin handle for the desired plugin module and uses its
functionality. For example:
plugin_pwd_qlty_check(plugin_handle, srv_handle, password,
use_policy, pol, principal);
where PWD_QLTY is plugin interface id and PWD_QLTY_KRB is its
This concludes the very basic overview. The details on how to write
plugin interfaces and implementations, please, refer to the
“Consequences” and “Sample Code” sections in the project proposal.
Now let me bring to your attention some updates.
1. 1. For those who followed the proposal since it was first
introduced (I guess, in April): we decided to remove Abstract
Interface for plugin manager. The initial motivation for having this
abstraction was to allow multiple implementations of plugin managers.
It thought to be useful for such cases as hardcoded configuration (as
for embedded devices), configuration that excludes the default
location search for dynamic plugins, or for asynchronous processing
model etc. However, since we do not have any immediate use-cases in
hands, for now we will implement only one plugin manager and reserve
the possibility of adding the abstraction later if needed.
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.
3. 3. Another interesting suggestion is for plugin interface to be
more generic and follow a request-response paradigm:
generic_collection *request, *response;.
/* 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);
/* 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);
In this case we do not ever need to change an interface,
however if the plugin module is not capable of returning some
information (because it is old, for example) we might be able to
ignore the absence of some data in the response if information
returned in the response collection is sufficient for us to continue.
All interfaces then have same signature and we never need to change or
add any new interface.
4. 4. Notion of the plugin properties configuration attribute. It
was introduced in the project to allow the administrator to pass some
additional information to the plugin manager. For example, to be
initialized, Plugin_A requires Plugin_B to be initialized first.
Plugin manager now would arrange the proper init order or pass the
desired parameters to the plugin module.
5. 5. The dynamic plugins handling section will be updated later
after the discussion on “Dynamic plugin modules and OS packages”
mailing thread concludes.
As always, your comments , suggestions and recommendations are very
tsitkova at mit.edu
More information about the krbdev