[bind10-dev] Ideas for modularity & hooks

[Michal 'vorner' Vaner]

Hello

On Thu, Feb 03, 2011 at 11:53:23AM +0100, Jelte Jansen wrote:
> 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).

Good point with the config. That is one another reason why we would want the
normal processing to be included in this. There are other points (some of which
I mentioned on the page):
 • Code reuse.
 • Testing.
 • Being able to remove the default action, to put custom actions before or
   after.
 • Easy building of hybrid servers.
 • Being able to mix python and C++ in one server.
 • Not having to write it twice, if we have a mechanism, we can use it as much
   as possible.
 • Ability to load new version of our own code.

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

Well, each of the lists would (or could) probably have different parameters and
return value. Config hooks probably don't need client context.

> 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 :) )

There are minor differences, but the idea is the same. Let's first talk about if
we want something in that direction, then tweak the details ;-).

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

Hmm, I wanted to call loops a programmer error (in the case, of the programmer
writing extension that caused the loop), just like any infinite loop. I don't
really expect any user or admin to write the extensions, just the enthusiastic
(they will enjoy some level of debugging anyway) and the big corporate ones with
specific needs, who probably will use big guns anyway, so this one would be
minor. On the other hand, it would most probably have some performance impact.

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

Agreed. I just wanted to show that it can be done.

Have a nice day

-- 
Anything is possible, unless it's not.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20110205/0fd5c825/attachment.bin>