[Bro-Dev] Configuration framework syntax proposal

[Johanna Amann]

I like that - I honestly did not really like configopt from the beginning,
the only reason for choosing it is that "config" conflicts with the
input/logging framework.

I am not completely sure we should deprecate const &redefs - there might
actually be a need for constants that can really only be changed on
startup. I like the idea of Jon to also remove the current ways to
manipulate &costs at runtime though :)

Johanna

On Fri, Sep 22, 2017 at 04:31:07PM +0000, Robin Sommer wrote:
> I was thinking the same when discussing an earlier proposal with
> Johanna. The "configopt" idea came out of that with the observation
> that "const &redef" isn't quite fitting here (and, as you say, it's
> already blurred anyways). At that time, however, the thinking was
> still to have a 2nd namespace, and writing 'configopt X: string
> &config="a.b.c"' seemed a bit too much. But if we just go with a more
> generic display name via Broxygen, then I'm back to liking it --
> except maybe for the name, how about "option" instead of "configopt"?
> So we'd arrive at something like this (similar to what has been said
> already):
> 
> module Foo;
> 
> export {
> 
>     ## The username for our new feature.
>     ##
>     ## Display: User Name
>     option user_name: string;
> 
>     }
> 
> And we could even start deprecating "const ... &redef" if we wanted.
> 
> Robin
> 
> On Fri, Sep 22, 2017 at 15:59 +0000, you wrote:
> 
> > 
> > > 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
> > 
> > _______________________________________________
> > bro-dev mailing list
> > bro-dev at bro.org
> > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
> > 
> 
> 
> 
> -- 
> Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin