[Bro-Dev] Feedback on configuration framework implementation

Jan Grashöfer jan.grashoefer at gmail.com
Thu Nov 30 09:57:57 PST 2017


On 29/11/17 23:02, Johanna Amann wrote:
> Hello everyone,
> 
> 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:

> option variable
> ===============
> 
> 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?

> config reader
> =============
> 
> 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")?

Thanks,
Jan


More information about the bro-dev mailing list