The oberservations / thoughts in this thread seem worth a ticket I'd say. We can refine this over time if the current semantics aren't quite ideal yet.
Robin On Tue, Oct 30, 2018 at 13:17 -0700, Christian Kreibich wrote: > Hi folks, > > I would agree that it takes a bit of experimentation to figure out > exactly when a change handler fires and how to reliably initialize or > update things based on an option's value. > > Consider this: > > module Foo; > > export { option foo = F; } > > function foo_handler(ID: string, foo_new: bool): bool > { > print fmt("New foo: %s", foo_new); > > # Update stuff here based on foo's value > # ... > > return foo_new; > } > > event bro_init() { > Option::set_change_handler("Foo::foo", foo_handler); > } > > ... foo_handler doesn't get called when you simply run the script > without redefing Config::config_files. When you do redef it, the handler > fires both when the config file sets foo to T, and when it sets it to F. > > So you have to make sure that your initialization happens even when the > handler doesn't get called, and you cannot write your handler assuming > that the new value is actually different from the old one. > > These arguably aren't bugs, but imo they do take getting used to. > > Best, > -C. > _______________________________________________ > bro-dev mailing list > bro-dev@bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev