[Bro-Dev] Configuration framework syntax proposal

[Johanna Amann]

Hello bro-dev,

in this email I want to get feedback on a possible syntax for the configuration
framework. The aim of the configuration framework is to provide an easy method
for Bro users and script writers to change configuration options during the
runtime of Bro (as opposed to only on startup as already possible using redef).

Let me start with an example what a script using the configuration framework
could look like:

========================================================================

module PcapFilter;

export {
	## Documentation goes here:
	## Set the PCAP filter that will be applied.
	const filter = "ip" &config="input.pcap.filter";
}

redef enum PcapFilterId += {
	NewFilter
};

function install_filter()
	{
	precompile_pcap_filter(NewFilter, filter);
	install_pcap_filter(NewFilter);
	}

# hook that is called when the configuration value changes
hook config_change(name: string, old_value: string)
	{
	install_filter();
	}

event bro_init()
	{
	# Register and cause the hook to be called on configuration changes
	Config::register_for_change("input.pcap.filter", config_change);
	install_filter();
	}

========================================================================

The two parts here are the definition of the configuration value and
an (optional) hook that can be defined to execute when a configuration option
changes.

The line 'const filter = "ip" &config="input.pcap.filter"' binds the constant
filter to the configuration option input.pcap.filter. When a user updates the
configuration option, the const will automatically change. For simple
configuration options, this line is all that is required to have a configurable
options.

For cases in which additional actions have to be performed when a configuration
option changes (e.g. calling BIFs), a hook can be registered to listen to the
change. The hook will be executed right after the value has been updated, gets
access to the previous value, and can perform any necessary actions.

Note that this proposal preserves typing: register_for_change will enforce that
the hook that is passed in (in this case config_change) will have a signature
that fits to the configuration option.

If a user desires to change a configuration option from script-land (e.g. in
local.bro), this is possible using 'Config::set'. For example:
Config::set("input.pcap.filter", "not ip");
Config::set also enforces typing and only accepts variables with the same type
as the const that was defined.

There obviously are a few more parts to this (storage backends, etc); however
these should be very flexible as we aim to implement as much as possible in the
script-land. There will be a few more BIFs that are necessary to write the
script-part of the config-framework; these are mainly needed for introspection.

In this email I am mostly interested in seeing if people think that this syntax
is a good idea, or if there are any better way to do this. I already talked
to a few people where a few other ideas were brought up, all having different
advantages or disadvantages. One idea is to have a different syntax to define
the configuration option. Instead of

const filter = "ip" &config="input.pcap.filter";

the definition could look like

configopt filter = "ip";

In this case, the name of the option would have to be automatically deduced and
look like "NameSpace::filter". The syntax is slightly nicer in this case, but
the configuration option naming is not as easy to structure.

So - I would be happy for any feedback or ideas on this.

Johanna