I just wanted to note that after keeping up on this thread that I agree with those same points. :)
.Seth On 21 Sep 2017, at 12:50, Johanna Amann wrote: >> 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 -- Seth Hall * Corelight, Inc * www.corelight.com _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
