[bind10-dev] Ideas for modularity & hooks

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/29/2011 12:57 PM, Michal 'vorner' Vaner wrote:
> Hello
> 
> As I promised, I wrote down some ideas about modularity and hooks and how to
> possibly do that. I put it as http://bind10.isc.org/wiki/modularity (and linked
> from the IdeasDump). Do you see any problems with it? Or a better way to do it?
> 

Some random comments and ideas;

I had an unrelated and undocumented plan to make each module consist of
dynamically loadable modules, but for a different reason than extensibility, and
I am not fully convinced yet that 'normal' processing should be a part of the
extension system (instead of the other way around), which I think is what you
are proposing here. I am also not opposed :) (I want modules to be loadable with
a specific set of functions anyway, so we can run specific module-code like
'verify this config' even if they are not running, for one).

What I did have in mind from the start was the part about chaining; each
extension point (which, in a model where core functionality would also be
implemented as extensions, would be just 1), would have a list of extensions,
which all contain a call with arguments like server-context, client-context,
question and answer-so-far (where client-context are things like adress of the
client, etc., and server-context provides access to the logger, resolver, etc.).

Each extension would be allowed to modify anything as it seems fit, and
depending on its return code a specific next action is taken. This may differ
from your list of four (but I may simply not understand your explanation of the
return values):

- - 'Ok, continue'; continue with the next extension in the list
- - 'Ok, done'; stop and return the answer as it currently is
- - 'Fail, drop'; stop and do nothing more
- - 'Restart'; restart with the first extension in the list (I actually had not
considered this yet, but i like it :) )

We certainly would need some form of loop-detection, and not only for restart
(for instance if a resolver action wants to resolve something resulting in the
same condition)

I personally don't think that big locks around the lists in case of
addition/removal of extensions are much of a problem for performance, we could
either temporarily stop service on the specific moment an element is
removed/added, or build a second list and replace it at once. Cases where the
lists are changed are rare I think.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1KiSMACgkQ4nZCKsdOncViMgCghlL20i6DdoHaolWLYZ/fW0Wo
pacAn3b1xmHEJCatwzL0IIyBYh11zkCM
=JjGS
-----END PGP SIGNATURE-----