[Date Prev][Date Next]
Re: question on RFC3062 - plugin API
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
(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)
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.
"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
> A client using the Password Modify Extended Operation need not
> know how the server chooses to store the user's password.