<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Just a short comment on who writes these list routines. I agree that
    most operations groups will just use things written by others.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    If you are looking for a few specific extension functions that could
    help the thought process along, here are a few:<br>
    Whitelisting and blacklisting in the recursive cache<br>
    caching for the auth server w/ SQL<br>
    putting clients in a "DNS walled garden"<br>
    special stat gathering<br>
    <br>
    jerry<br>
    <br>
    On 02/05/2011 01:01 AM, Michal 'vorner' Vaner wrote:
    <blockquote cite="mid:20110205090108.GA12943@tarantula" type="cite">
      <pre wrap="">Hello

On Thu, Feb 03, 2011 at 11:53:23AM +0100, Jelte Jansen wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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).
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre wrap="">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.).
</pre>
      </blockquote>
      <pre wrap="">
Well, each of the lists would (or could) probably have different parameters and
return value. Config hooks probably don't need client context.

</pre>
      <blockquote type="cite">
        <pre wrap="">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 :) )
</pre>
      </blockquote>
      <pre wrap="">
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 ;-).

</pre>
      <blockquote type="cite">
        <pre wrap="">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)
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
Agreed. I just wanted to show that it can be done.

Have a nice day

</pre>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
bind10-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind10-dev@lists.isc.org">bind10-dev@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind10-dev">https://lists.isc.org/mailman/listinfo/bind10-dev</a>
</pre>
    </blockquote>
  </body>
</html>