[Kea-users] Need help defining custom options

James Sumners JamesSumners at clayton.edu
Tue Jan 31 19:58:31 UTC 2017


My argument would be that it is better for the user. Look at the HAProxy 1.6 announement[1]: “Those who uses HAProxy for a long time will be happy to know that ‘\ ‘ (backslash-space) sequence is an old painful souvenir with 1.6.” Escaping is so cumbersome that their removal of it lead off the feature list in a very major release.

[1] — http://blog.haproxy.com/2015/10/14/whats-new-in-haproxy–1–6/




On January 31, 2017 at 2:35:26 PM, Tomek Mrugalski (tomasz at isc.org<mailto:tomasz at isc.org>) wrote:

We thought about similar thing and discussed it some degree with the
team, but decided against it. There are couple reasons for that.
First, the parser would get very complicated. Keep in mind that we allow
custom options to have records and you can have multiple records in a
single option. The number of different ways to encode the same option
would grow significantly with all the implications of it. The
documentation would get more complex and some users would wonder whether
one way is better than another.

Finally, there's the argument of breaking up existing deployments. Kea
is relatively new software, but I like to believe that it is being used
in some deployments. The change you propose would break down existing
deployments. Also, Kea is using a JSON syntax that is easily generated.
There are systems built around Kea that generate the configuration.
Those would break down too and would have to be updated.

We did not promise to never change the syntax, but we will need a very
good argument why we're breaking compatibility with older configurations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20170131/a161a9aa/attachment.htm>


More information about the Kea-users mailing list