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
