[Bro-Dev] Configuration framework syntax proposal

[Siwek, Jon]

> On Sep 21, 2017, at 8:18 AM, Seth Hall <seth at corelight.com> wrote:
> 
> Yep, this notion of making things abstract-able into easy configuration 
> interfaces and/or good documentation (using the inline broxygen 
> comments) was always in the proposal, Johanna pointed it out in the 
> original code sample.

Yeah, I was wondering what a UI would currently look like if you tried to use existing functionality, e.g. just identifier names and broxygen comments. Like Jan, I had a hard time understanding the benefit having two names for the same value: the identifier and config string.  It seems to push more burden than needed onto script authors, like maybe they don’t really care about a UI, but want the improved configuration capabilities.  i.e. maybe the requirements of a UI can be separate from the requirements of the new “configuration variables” concept.

Maybe one thing to do is try to actually build/design your ideal UI and/or configuration tool starting with just the existing Bro functionality.  You’ll definitely get an understanding of the low-level requirements that way.  i.e. first design/build the most basic user experience that functionally works and then, from that state, add whatever you think will be an improvement.

> There is just something about the idea of exposing variable names to 
> users (even if it's wrapped in a gui) that is intensely unpalatable to 
> me.  It's pretty much unheard of among other types of software.  It 
> would be like exposing internal variable names to command line programs 
> instead of abstracting it into easy flags (i.e. -a or --help) or, if in 
> a gui a text entry box had a label next to it like 
> "GUI::My_Program::user_name" instead of showing "Username".

I’m half facetious in bringing it up, but have you seen CMake? https://cmake.org/runningcmake/

- Jon