[Kea-users] Need help defining custom options

[Tomek Mrugalski]

W dniu 31.01.2017 o 14:36, James Sumners pisze:
> Documentation wouldn’t be too difficult:
> 
>     When the |data| field is a |string|, and that string contains the
>     comma (|,|; U+002C) character, the comma must be escaped with a two
>     reverse solidus characters (|\\|; U+005C). For example, the string
>     |foo,bar| would be |foo\\,bar|.
> 
> However, I’m not sure that escaping is the best route. It is clear to me
> that the problem stems from the fact that the |data| property can either
> only be a CSV value or a binary value. My suggestion for a more robust
> fix would be to remove the |csv-format| property and replace it with a
> |format| property. The new |format| property could accept the string
> values: ‘csv’, ‘binary’, or ‘literal’. The default could remain ‘csv’,
> and the case under discussion would be ‘literal’. This would also
> provide the possibility for other value types in the future.
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.

On a related note, the approach your proposed is a good idea and perhaps
we will implement it one day. But it is unlikely to happen in the near
future. Kea is developed by a very small team and our engineering
resources are very limited. If we spent some time on this, we would
improve existing feature. You could do the same you can do now, albeit
in more convenient way. On the other hand, if we spend time on
developing something new, we can enable things that were previously not
possible. That gives us a bias towards developing new features, rather
than refining existing ones.

Hope that explanation makes sense.

Tomek