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 _______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
