[kea-dev] Specifying parameters for hook libraries

[Tomek Mrugalski]

With Kea 1.0 we have changed the hook library definition syntax:

    "hooks-libraries": [
        {
            "library": "/opt/charging.so"
        },
        {
            "library": "/opt/local/notification.so"
        }
    ]

As part of the #4297 work, I extended the syntax to allow parameters:

"hooks-libraries": [
    {
        "library": "/opt/charging.so",
        "parameters": {}
    },
    {
        "library": "/opt/local/notification.so",
        "parameters": {
            "debug": false,
            "urgency_level": 42,
            "mail": "spam at example.com"
        }
    }
]

I'm working on the ability to add parameters for hook libraries (see
ticket #4297). I have updated LibraryManagerCollection to store those
parameters. They're stored as ConstElementPtr. This way the code can
handle arbitrary structure within "parameters". Now the question is how
to expose those to the library?

The simplest way would be to extend LibraryHandle with method:

ConstElementPtr LibraryHandle::getParameter(string name)

This is the most flexible approach. It allows handling data structures
of arbitrary complexity, including strings, booleans, integers, real
numbers, maps, lists, maps of maps, lists of maps or even more complex
structures. However, it has two disadvantages of requiring cc/data.h to
be included in hooks/library_handle.h (which currently does not depend
on anything) and depending on libkea-cc. The second disadvantage can be
alleviated by moving cc/data.h to libkea-util, as it seems to be used in
more and more places throughout the code.

Alternative approach would be to implement getters:

string LibraryHandle::getParameterString(string name);
int LibraryHandle::getParameterInt(string name);
bool LibraryHandle::getParameterBool(string name);

This has the advantage of not depending on cc/data.h and does not
require hook writers to understand how to use ElementPtr class.
On the other hand, it seriously limits the type of configuration
that can be handled. In particular it would prevent lists and maps or
more complex structures from being usable. We could add wrappers for
them too, but then people would possibly want maps of maps, list of maps
etc. And this is not something we could write wrappers for.

Thoughts?

Tomek