[kea-dev] Specifying parameters for hook libraries

Chaigneau, Nicolas nicolas.chaigneau at capgemini.com
Thu Mar 10 08:41:46 UTC 2016


> 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?




Although I'm currently only using simple parameters, I do like the flexibility of the first method.

I don't think the added dependencies matter at all. The hooks are supposed to be used with Kea anyway.
And the code required to use ElementPtr with simple data types is not really more complicated than getters.

Just make sure to include examples in the documentation, especially for the more complex structures. :)


Regards,
Nicolas.



This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.



More information about the kea-dev mailing list