[kea-dev] Hooks libraries and configuration information

[Tomek Mrugalski]

Oops, I realized that I never responded to that discussion.

On 02.09.2015 13:00, Stephen Morris wrote:
> On 01/09/2015 19:22, Thomas Markwalder wrote:
>> On 9/1/15 12:51 PM, Stephen Morris wrote:
> However, if we allow for a getMyParameters() call, there seems no reason
> why we couldn't allow something like:
> 
> {
>   "Dhcp4": {
>        :
>     "hooks-libraries" : [
>       {
>         "library" : "/opt/charging.so",
>         "parameter-set" : {
>            "alpha": "beta",
>            "foo": "bar"
>         }
>       },
>       {
>         "library" : "/opt/local/notification.so",
>         "parameter-set" : {
>           "param1" : "value"
>         }
>       }
>     ]
>   }
> }
I like this structure. It has a number of advantages. Parameters are
separated clearly. It is obvious to which library a a given parameter
will apply. There are no collisions. No need to attempt uniqueness in
distributed manner, which would make the parameter names awkward (I
prefer 'debug' rather then 'some_company_lib1_debug').

The disadvantage is that the syntax will change compared to 0.9.2 or
earlier. I don't think this is a big problem, though. We do our best to
limit those type of changes, but we never guaranteed that the parameters
will be stable between revisions. Documenting the change in release
notes should do the trick.

> I think that the right solution might be to allow both forms, and layer
> the "getMyParameters()" on a general configuration access mechanism.
I'm against that. With allowing 2 forms you will get the worst of two
approaches with extra problems on top of it. What if there's a parameter
in two places? Which takes precedence? Think about common names, like
enabled, verbose or debug. Many libs are likely to provide such
parameters. You'd have to implement some sort of conflict resolution.
And a config syntax that allows conflicts by design is poorly designed
in my opinion.

With the approach you proposed above as being the only way to configura
parameters, it is clear, easy to understand and easy to implement.

One minor nitpick: parameter-set should be parameters. I had to convey
similar type of information (command + parameters) and went with
"command" (a string) and "arguments" (a map). On reflection, I would
rename "arguments" to "parameters", simply because it makes the natural
JSON representation more intuitive. That's convenient in unit-tests,
where toText() representation spits out JSON structures in alphabetic
order and it's more convenient to have command printed before its
parameters. Sadly, I realized that too late in the process and we're
stuck with arguments+command rather than command+parameters.

BTW while I was designing statistics, I thought that parameters could be
a generic JSON structure that would be library-specific: a map, string
or list of parameters. However, I gave up on the idea and made it a map.
It's marginally more complex, but then you're able to process all
parameters for all libraries in an uniform way.

Tomek