[bind10-dev] Ideas for modularity & hooks

[Jerry Scharf]

Hi,

First, this sounds really exciting, I hope something like this comes to 
pass. I am going to use some clumsy words here, but good terms for what 
the place where a list exists and what the elements of the list are 
called. I called them processing points and processing elements, which I 
hope capture the concept. The terms I would use for the return states 
would be: finish, fail, continue and restart. Restart seems like a 
"weapon of self destruction", but it sounds like Apache has survived 
with the functionality.

This draws my mind to how one would configure this type of capability. 
For a general case, there would be a tree of processing points to 
control (a processing element loaded could introduce processing points 
within it.) It also seems clear from the description that there are data 
elements that processing elements can manipulate. I am going to posit 
that there is nothing in the configuration that is needed for the data 
elements, just the lists. (these data elements may drive dependencies)

To specify an processing element, we need to specify the name of the 
element, possibly a version, the source from which the element is loaded 
and the position of this element in the list. There was a discussion of 
dependency for processing elements, so that would also need to be 
addressed. If a processing element was added as a dependency, we want to 
tag that so that when the primary element that needed it goes away the 
element installed as a dependency goes away as well.

There almost certainly needs to be a default list for each control point 
so the system can come up working before the configuration is modified. 
If it is determined that this is only for exception processing, the 
default becomes null.

In terms of what an operator needs to do with this, here is a quick list 
I came up with:
add/modify/delete the files that contain the elements
show the element list at a processing point, expand the list to where 
elements come from
View the dependencies for a processing element
test dependency for an element at position x on a list
insert an element into a list at position x
modify/remove an element from the list
control server response to missing file/element in file for a list element
restore default list
dump all non-empty lists for all processing points (part of show tech)

Questions:
Can we assume that the lists will be short, say <10 elements?
What happens to an element list when the processing point it's 
associated with goes away?
What exactly drives element dependencies?
Can you get into order dependency problems?
how best to present/manage the insert at position x?
How will element versions and version management fit into this?
Will this get extended to include a matching clause like a general ACL?

jerry

On 02/03/2011 02:53 AM, Jelte Jansen wrote:
> -----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-----
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev