On 29/11/17 23:02, Johanna Amann wrote:
the branch topic/johanna/config contains an implementation of the
configuration framework as it was discussed in an earlier thread on this
list. GitHub link: https://github.com/bro/bro/compare/topic/johanna/config
Nice! I am curious to see all the usability improvements that can be
built on top of this.
It would be great if people could take a look at all
of this and see if
this makes sense, or if they see any problems with the implementation as
it is at the moment.
Having I quick look at the documentation, everything seems well
though-out to me. I have just two small questions:
The option keyword allows variables to be specified as run-tine options.
Such variables cannot be changed using normal assignments. Instead, they
can be changed using Option::set. It is possible to "subscribe" to
options and be notified when an option value changes.
Change handlers can also change values before they are applied; this
gives them the opportunity to reject changes. Priorities can be
specified if there are several handlers for one option.
1. Thinking of handlers that may change values and are associated with a
priority, hooks come to my mind (e.g. Intel::extend_match). Are
functions preferable compared to hooks here?
The config reader provides a way to read configuration files back into
Bro. Most importantly it automatically converts values to the correct
types. This is important because it is at least inconvenient (and
sometimes near impossible) to perform the necessary type conversions in
Bro scripts themselves. This is especially true for sets/vectors.
Configuration generally look like this:
[option name][tab/spaces][new variable value]
2. Are module namespaces part of the option name (e.g.
"Notice::reply_to" vs. "reply_to")?