[Bro-Dev] Configuration framework syntax proposal

[Johanna Amann]

> I think that it's important to have this behavior come with a reasonable
> default. I think that whatever we choose should just work out of the box.
> For example, I think the existing construct should continue to work:
> 
> > const user_name: string &redef

I agree; note that what I proposed preserves this compatibility (it does
not change anything at all about redefs). 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).

> At the end of the day, what we're discussing is how a developer should
> document and expose a feature to an end-user. If, as a developer, I choose
> a bad variable name, then I'm not providing a good experience for the
> end-user, but that's my decision. I don't think that forcing developers to
> essentially add documentation via syntactic sugar is the right approach. If
> their variable names are confusing, people are less likely to use their
> script.
> 
> I think that a lot of what users might want to re-configure is too complex
> to be explained through a variable name anyway. We already have a system in
> place to document variables, and I think that we need to rely on that
> instead of focusing so much on which name is exposed to the user.

I agree with this.

> As we look at moving Bro scripts to packages, I think we need to look at
> how other package repositories have handled similar configuration options.
> Puppet Forge, for instance, has a types tab which documents the names of
> the parameters, and what they do:
> https://forge.puppet.com/puppetlabs/mysql/types This would be pretty easy
> to do with the Broxygen documentation, and a UI could also expose this.

Yup, I also agree with this.

Johanna