> On Sep 21, 2017, at 11:50 AM, Johanna Amann <[email protected]> wrote: > > The feature that the > configuration feature wants to bring is the ability to change options > during runtime - which cannot be accomplished with redefs. redef-able > consts will still have their place afterwards (for everything that still > cannot be changed during runtime).
Just had a misc. thought related to the use of ‘const’: I remember first being confused/unfamiliar with Bro’s use of ‘const’ and thought it meant “never changes” only to learn it’s further qualified as “never changes at run-time” so that the ‘const’ + ‘&redef’ combo ultimately means “never changes at run-time, but initial value may be changed at parse-time”. Though, technically, ‘const’ can still be modified at run-time, if you know how… e.g. send_id... And that’s maybe all ok -- it’s easy to explain unfamiliar context as I did above and the means of subverting runtime modification restrictions isn’t actively advertised as such. Though, with a new config framework, there’s opportunities: 1) could remove need for the backdoor method of modifying ‘const’ values at runtime, (e.g. via send_id) as that’s done through new identifiers explicitly tagged for config purposes 2) using a new ‘configopt’ access modifier may be warranted over re-using ‘const’ for configuration values as the semantics are now blatantly different than what ‘const’ is expected to mean. i.e. config values are meant to change at run-time, but only via a restricted API and ‘const’ is still intended to never change at run-time - Jon _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
