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 <[email protected]> Sent: Tuesday, October 30, 2018 3:41:00 PM To: Hosom, Stephen M Cc: [email protected] 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 <[email protected]> wrote: > > I bumped into a limitation that was a little frustrating to work around with > the config framework. > > > 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 other files. — Justin Azoff _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
