Send kea-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/kea-dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of kea-dev digest..."
Today's Topics:
1. Specifying parameters for hook libraries (Tomek Mrugalski)
2. Re: Specifying parameters for hook libraries (Chaigneau, Nicolas)
3. Re: Specifying parameters for hook libraries (Francis Dupont)
----------------------------------------------------------------------
Message: 1
Date: Wed, 9 Mar 2016 21:17:29 +0100
From: Tomek Mrugalski <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [kea-dev] Specifying parameters for hook libraries
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
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": "[email protected]"
}
}
]
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
------------------------------
Message: 2
Date: Thu, 10 Mar 2016 08:41:46 +0000
From: "Chaigneau, Nicolas" <[email protected]>
To: Tomek Mrugalski <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [kea-dev] Specifying parameters for hook libraries
Message-ID:
<ab94b0b675bdf14189cd5a861db36c8459917...@de-cm-mbx26.corp.capgemini.com>
Content-Type: text/plain; charset="us-ascii"
> 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": "[email protected]"
> }
> }
> ]
>
> 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.
------------------------------
Message: 3
Date: Thu, 10 Mar 2016 09:00:39 +0000
From: Francis Dupont <[email protected]>
To: Tomek Mrugalski <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [kea-dev] Specifying parameters for hook libraries
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Tomek Mrugalski writes:
> ... 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.
=> IMHO it is the way to go and perhaps a good occasion to fix the
cc / config library mess. So I have no problem to move cc/data.* to
an lib/util subdirectory and cc/command_interpreter.* to lib/config.
BTW there is a ticket about cc/config merge/reorg.
Regards
Francis Dupont <[email protected]>
PS: we can use flex/bison vs current home made code to parse JSON
(there are a large number of examples in the web). The only major
incompatibility is in location (we have line + (begin)position when
flex/bison has line + (begin-end)positions which BTW can be considered
as an improvement but requires to update a lot of unit tests).
For speed on the paper flex/bison is faster but JSON is so simple
I don't believe in a significant difference.
------------------------------
_______________________________________________
kea-dev mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-dev
End of kea-dev Digest, Vol 24, Issue 2
**************************************
