> 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 _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
