[bind10-dev] Comments on proposed hooks framework

[Michal 'vorner' Vaner]

Hello

On Wed, May 15, 2013 at 11:59:53AM +0100, Tomek Mrugalski wrote:
> > 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.

I don't think it will be that much more work. I guess the framework will take
some time to implement. But then, the difference between:

context.set(…);
result = HookFramework.call("pre-perform-action", context);
if (result.failure()) {
  throw Failed();
}
if (!result.skip()) {
  performAction(context);
}

and

context.set(…);
result = HookFramework.call("pre-perform-action", context);
if (result.failure()) {
  throw Failed();
}
if (!result.skip()) {
  performAction(context);
}
result = HookFramework.call("post-perform-action", context);
if (result.failure()) {
  throw Failed();
}

will be pretty small.

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

Actually, I think it'll make it easier for many languages. In python, the
lifetime of objects is hard to track. So you'd either need to keep the pointer
alive as long as the python object is alive, or create a copy whenever you wrap
the pointer to python object. With shared pointers, you can copy the shared
pointer and be happy, as it will keep the real object alive as long as the
python one lives.

There might be some problem with C to be sure, but I think we said we'll support
C++ natively and not care about C that much.

With regards

-- 
Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary.  No such faith comforts the software
engineer.
                -- Fred Brooks

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20130515/8acd31f3/attachment.bin>