[bind10-dev] Ideas for modularity & hooks

[Jerry Scharf]

Just a short comment on who writes these list routines. I agree that 
most operations groups will just use things written by others.

The biggest concern I have is that somehow extension A and extensin B, 
written by different folks will somehow have unpleasant 
incompatibilities. So when poor operator puts both elements in because 
it sound like they both can be useful, nasty things happen. It is both 
nasty for the person in the middle and unclear who should change what to 
make life better.

This may just be the risk of using extensions, but whatever can be done 
from a design perspective to minimize this situation would make the 
extension system safer and more likely to be used.

If you are looking for a few specific extension functions that could 
help the thought process along, here are a few:
Whitelisting and blacklisting in the recursive cache
caching for the auth server w/ SQL
putting clients in a "DNS walled garden"
special stat gathering

jerry

On 02/05/2011 01:01 AM, Michal 'vorner' Vaner wrote:
> 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
>
>
>
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20110205/cb43cb69/attachment.html>