[bind10-dev] Comments on proposed hooks framework

[Michal 'vorner' Vaner]

Hello

On Tue, May 14, 2013 at 11:54:23AM +0100, Stephen Morris wrote:
> SUCCESS = All OK, return from callback and call hook from next library.
> COMPLETE = All OK, return from callback without calling hook from next
> library.
> 
> SUCCESS_SKIP, COMPLETE_SKIP = As above, but return indication to
> calling program that it should skip the next step of processing.

So maybe not have SUCCESS_SKIP, but only COMPLETE_SKIP? So you'd skip the rest
of plugins too?

Also, maybe it would make sense returning something compound, not just enum? One
part for the error code, one part for error text, one part for the skipping, etc.

> > 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.
> 
> This has been proposed because of speed.  A get/set interface implies
> copying parameter information - copying into the CalloutHandle and
> then copying it out again.  That will cause problems when passing
> complicated structures around as well as preventing the passing to
> callouts of objects declared as singletons.

Well, you could still have something like set with shared pointer, or such. So
you'd copy the pointer (which you do now too), but not the data itself.

> The above interface just passes pointers to the objects in the calling
> program.  A programmer writing a library just has to observe the
> simple rule: "don't delete objects passed as parameters or something
> bad will happen".

Not really. What if the programmer adds some more? Or replaces the old? Who
deletes this one?

> > 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.
> 
> The above method of storing data types does not prohibit this.
> However, from what you are saying, when we come to writing the
> bindings for other languages, we would need to add type information
> about the parameters.
> 
> The current proposal includes a "registerHook()" call: at the time we
> come to extend the hooks to other languages, we could extend the
> framework with a "registerHookParameter" call, e.g.
> 
> Hook la_pre = registerHook("ia_lease_assign_pre");
> registerHookParameter(la_pre, "query", TYPE_PKT4PTR);
> registerHookParameter(la_pre, "reply", TYPE_PKT4PTR);

We don't really need that. The context could keep types as well as the values.
In the set method (or whatever it would be), the type is known, because it is
templated. So we can store some ID of the type with the value.

With regards

-- 
2 keys should be enough for everyone

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/71c15aab/attachment.bin>