[Bro-Dev] Configuration framework syntax proposal

[Siwek, Jon]

> On Sep 21, 2017, at 11:50 AM, Johanna Amann <johanna at corelight.com> 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