Plugin project proposal

[Zhanna Tsitkova]

Moving the initial Plugin Improvements project proposal to the mailing  
thread independent from "design choices for a loadable module  
interface" thread.


Hello,

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  
implementations;
Plugin Loader Implementation (PLI) - Concrete implementation of PL. It  
knows about the set of the available implementations and how to create  
them;
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  
to PLI.

 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_manager_get_service(ctx->pl_manager, PWD_QLTY,  
PWD_QLTY_KRB, &plugin_handle);

         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  
implementation id.

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;.

        ....

       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);

       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  
much appreciated



Thanks,

Zhanna



Zhanna Tsitkova
tsitkova at mit.edu