[bind10-dev] Comments on proposed hooks framework

[Tomek Mrugalski]

On 13-05-15 07:45, Michal 'vorner' Vaner wrote:
> Hello
> 
> On Tue, May 14, 2013 at 05:01:50PM +0100, Tomek Mrugalski wrote:
>>> Maybe, instead of calling it SKIP, call it OVERRIDE or REPLACE?
>>> So it is clearer what is meant?
>> We came up with an idea to do pre- and post-action hooks.
>> OVERRIDE status would make the post-action hooks obsolete. I
>> think it is a reasonable trade-off. Nevertheless, OVERRIDE
>> applicability will be defined on a pre-hook basis. In particular,
>> DHCP is unlikely to support it at the early implementation
>> phase.
> 
> You mean like if you return OVERRIDE from pre-* hook, the post-*
> hook does not get called?
> 
> Strictly speaking, I don't think it would be necessary. If the
> pre-* hook just replaces the default action, you still can have
> hooks after the non-default one.
> 
> But obviously, OVERRIDE makes no sense as return value from the
> post-* hook.
The consideration here is to avoid duplication. Some operations are
costly, e.g. lease selection. It doesn't make sense for the server to
laboriously select a lease just for the hook to override it later. On
more thought I think pre- and post-action hooks are needed after all.

Here are 2 cases that show that

CASE 1:
- pre-action hook sets overridden values and returns OVERRIDE
- server action is skipped as the hook is already did the job
- post-action is not called

CASE 2:
- pre-action hook does nothing
- server action does something, e.g. selects lease
- post-action gets the results of the action, e.g. selected lease. the
post-action call out does something with it, e.g. logs it.

To cover those valid use cases, I'm afraid we need both OVERRIDE and
pre-/post-action hooks. That unfortunate, because it will take more
work to implement them.

> The other example was, I have a family of plugins (they all work
> with my database, let's say). I want to be able to enable and
> disable them individually, so they have to be separate libraries.
> But they need to pass information from one to another with each
> packet.
> 
> And, with pointers, that's why I said I don't really like them. If
> they were shared pointers, the problem would be solved.
Shared pointers would work for C++ libraries, but it will be
problematic to use it in libraries written in different languagues.

Tomek