[bind10-dev] Comments on proposed hooks framework

[Tomek Mrugalski]

On 13-05-14 07:43, Michal 'vorner' Vaner wrote:
>> However, I concede that it does introduce some confusion.  I
>> suggest removing the SKIP codes: if a hook can allow the callout
>> to signal "skip" functionality, it can do so via a parameter.
> 
> Could you point me to a hook that does not make sense to allow
> replacing the internal behaviour?
> 
> 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.

>> Looking back at the interface for the get/set, is set() really
>> needed? I'm thinking that it would be better to pass everything
>> as pointers:
> Yes. Library may want to add a parameter that did not exist before,
> and keep it there for later.
For what purpose? To use it by some other callout? Adding new
parameter would bring in many issues with little benefit. Stephen
proposed the parameters to be passed by pointers to avoid copying. But
who would clean up the pointer that the user library sets? How long
the pointer is valid? I was thinking that set() can be used by user
library to set already specified parameter and would be used to things
like override the outgoing interface name, packet destination address etc.

>> CalloutHandle::parameter(const char* name, T*& param_ptr);
> 
> I'm not sure about this interface. I believe it is more common in
> C++ to have get and set separated, than one universal method that
> can be abused to do both. Also, the raw pointer there smells like a
> place to create bugs.
Agree on both.

Tomek