[Freeipa-devel] [PATCH] Add interface for baseldap plugins to register additional callbacks.

[Pavel Zůna]

Rob Crittenden wrote:
> Pavel Zůna wrote:
>> This is somewhat of a tech-preview patch. It works, but the whole 
>> concept might need some more work/thinking done.
>>
>> It adds another way to extend plugins without resorting to the 
>> versioning system.
>>
>> Until now, every baseldap command had two callbacks. The pre-callback 
>> called before data was passed to python-ldap and the post-callback 
>> called after.
>>
>> This patch introduces class methods, that enable the registration of 
>> new pre/post callbacks. It supports top level functions as well, so 
>> you don't have to touch the original class at all.
>>
>> It works likes this:
>>
>> from ipalib.plugins.user import user_show
>>
>> def test_callback(inst, ldap, dn, attrs_list, *keys, **options):
>>     inst.log.info('hello callback world!')
>>     attrs_list = ['uid'] # only retrieve the user name
>>     return dn
>>
>> user_show.register_pre_callback(test_callback)
>>
>> The original callbacks defined in the class are always called first.
>>
>> Pavel
> 
> I think I'd like another registration argument, sort of a hint on where 
> you'd like this plugin registered: first or last (defaulting to last). 
> We wouldn't necessarily guarantee where the plugin would get registered 
> but we could easily handle prepending or appending the new registration.
The argument is already there, but as you said, it doesn't guarantee a 
specific order. The "in-class" callback is added when the plugin 
instance is created and is inserted at the beginning of the list. More 
callbacks could be theoretically added later before this one, but that 
probably won't happen.

> Not sure how complicated we want this to be but we could also add a 
> dependency system, so that if some other callback is registered, then 
> this one comes first (or registration fails), etc.
A priority system might be better and easier to implement in this case. 
I'm also thinking of making the callback signature common for all 
commands (even though they have different "needs") and adding a context 
variable callbacks could use to pass data to each other.

> rob

By the way, the approach with class methods and class attributes I'm 
using is 100% compatible with the versioning system I proposed before. 
You can do this for example:

class user_show(...):
    VERSION = (1, 0)
    ...

user_show.register_pre_callback(some_callback)
user.show_register_pre_callback(some_other_callback)

class user_show(user_show):
    VERSION = (1, 1)
    ...

And the new user_show class will have all the callbacks for the previous 
version. Isn't that cool? Man, I love python. It's the hackers holy 
grail. :D

Pavel