[bind10-dev] Comments on proposed hooks framework

[Michal 'vorner' Vaner]

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.

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

I was giving an example (obviously, model one). I have some customers. I don't
want to answer queries to non-customers. And I want to provide answers
translated to their language. Information about customers is stored in a
database.

There are two points I want to hook. Even before I start to process the query
(after parsing). I need to look into the database and check login information
that was in the packet against the database. The second place is after the
answer is found, when I want to translate it. But I don't want to access the
database twice, so I get the language with the login info and store it for
future somewhere.

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.

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/20130515/50daf620/attachment.bin>