Re: question on RFC3062 - plugin API

[Kervin Pierre <kpierre@fit.edu>]

Hi,

Ok, as you suggested a took a look at the source and I'd like to extend
the existing API.  Here's briefly what I have in mind.

I'd like to see a mechanism in place where a plugins could...

(i)  Register at server startup.  Plugin order could be specified in a
config file (slapd.conf?)

(ii) The module registers as a pre-operation or post-operation plugin. 
Pre-operation plugins get to examine incoming request.  Post-operation
plugins get to examine the result of the operation.  I'm not sure
whether one would want to allow a module to modify request or results,
but that's certainly a future option.  Plugins can veto an operation.

(iii) The plugin decides what type of operation it is passed but this
would be limited to type only.  eg.  A module could register for
peroperation on adds (it's registered "pre add" functions would be
called at the beginning of do_add()).  This module would not affect
searches, deletes etc.

(iii) Every enabled pre-operation plugin would have a registered
function called before the operation is completed.  After a preliminary
look, I'd say at the beginning of the "do_*" functions.  The function
would receive a reference of the same information passed to the calling
function.

(iv)  Every enabled post-operation plugin would have a registered
function called after the operation is completed.  After a preliminary
look, I'd say at the end of the "do_*" functions.  The function would
receive a reference to the results of that operation. 

At the beginning of a do_* ( eg. do_add ) function one'd have

if(add_pre_plugin_list != NULL)
{
	//module stuff
	...
}

then something similar at the end of the function.  Thus the non-plugin
code path is virtually unaffected.

The API would need to be ironed out, although I think the arguements for
the functions would be mostly the same as their calling functions (ie.
the do_* functions )

I'd like to work on this.

-Kervin


"Kurt D. Zeilenga" wrote:
> 
> At 06:37 PM 7/5/2001, Kervin Pierre wrote:
> >Is the plugin API documented?  I know it's experimental.  If it is,
> >where can I find this documentation.
> 
> in the source files :-)
> 
> >Specifically I'd like ...
> 
> The API allows for backends to be plugged in.  I don't it
> supports what you're after.  You're welcomed to extend it.
> 
> >I took a look at 3112.  Is this suppose to be a replacement to the
> >common habit of adding the encryption type before the value in the
> >userpassword attribute?
> 
> Basically, yes.
> 
> >Another potentially stupid question is, how is 3062 different from
> >sending a ldapmodify request on a the userpassword attribute as that
> >user?
> 
> A client using the Password Modify Extended Operation need not
> know how the server chooses to store the user's password.
> 
> Kurt