[Bro-Dev] Configuration framework syntax proposal

[Seth Hall]

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
> bro-dev at bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

--
Seth Hall * Corelight, Inc * www.corelight.com