I agree that more complex code on my side would definitely make this a non-issue.
In my case, I was setting up something in bro_init that would be used repeatedly
throughout execution, and you're right--my code never handled option updates.
In this case, I opted to just use old redefable consts, as they will perform exactly as
expected for any downstream users (changes require a bro restart).
Honestly, I only brought this up at all because I can definitely see a person new to
scripting wondering why their options do not have the expected values at bro_init time and
troubleshooting for hours.
Maybe it would be worthwhile to just add a note in the documentation for the config
framework about it and leave it at that?
From: Azoff, Justin S <jazoff(a)illinois.edu>
Sent: Tuesday, October 30, 2018 3:41:00 PM
To: Hosom, Stephen M
Subject: Re: [Bro-Dev] Config Framework Feedback
Message received from outside the Battelle network. Carefully examine it before you open
any links or attachments.
On Oct 30, 2018, at 2:09 PM, Hosom, Stephen M
I bumped into a limitation that was a little frustrating to work around with the config
It is inconvenient that values stored in files read by adding to Config::config_files are
not available within the bro_init event. After reviewing how the Config framework works, I
understand why this is the case, but it means that if you want to use configuration values
on startup, you're not guaranteed to be working with the anticipated value.
I think the introduction of an event that ensures that configuration files have been read
by the time that the event fires might be worthwhile. I was wondering if anyone had any
thoughts on how to resolve/work-around this issue.
This is an issue, but probably not the one you are thinking of. even if configuration
files were fully read by the time bro_init was ran, you'd still need to handle the
value changing at runtime.
If you need to run code when an option changes, you can use the Option::set_change_handler
to make bro raise an event. Using this instead of bro_init would fix the startup problem,
and handle it changing at any time.
There's a test that uses this in testing/btest/core/option-priorities.bro and a few