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 <joha...@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@bro.org
> > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
> >
>
>
>
> --
> Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
