[Bro-Dev] Configuration framework syntax proposal

[Robin Sommer]

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