[bind10-dev] Comments on proposed hooks framework

[Michal 'vorner' Vaner]

Hello

On Mon, May 13, 2013 at 02:44:32PM +0100, Stephen Morris wrote:
> 1. Whether to require the user to register callbacks.
> 
> Having the user-written library export functions of the appropriate
> name or requiring the hook library register them are equally valid
> ways of working.

I think it makes sense to support both modes somehow. At least in the long term,
if not from the beginning.

> On reflection - and for the first implementation at least - I think that
> it would be best to have per-library lists, so it will be up to a
> library to register multiple callbacks for a hook point in the correct
> order.

Actually, my point was about callbacks of different libraries. You don't really
need multiple callbacks of the same library for the single hook point, if
there's nothing foreign in between them. You can have one and then call all your
sub-callbacks from there if you want.

It is the order of libraries that matters.

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

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

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

> > We need to have the ability to pass
> > const arguments to user library (see my previous comment about
> > passing pieces of configuration for example use case).
> 
> See above with regards to boost::any.

I'm not against boost::any, that sounds like something we may want. But, I don't
know if we want to allow any type to be passed.

My motivation here is being able to write bindings to other languages. You need
some mechanism to convert/wrap the types to the given language (be it python or
something else) and for that, you probably need to know the list of supported
types in advance.

With regards

-- 
Never underestimate the bandwidth of a station wagon full of HDDs.

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/20130514/964e6a3d/attachment.bin>