[Bro-Dev] Configuration framework syntax proposal

[Seth Hall]

On 21 Sep 2017, at 4:17, Jan Grashöfer wrote:

> While I agree that there are two (more or less) distinct groups and 
> that
> the notion of configuration should be separated from the notion of
> brogramming, I don't think that anyone would profit from introducing
> something like &config="just.another.name". Because of the additional
> name mapping, this will make scripts harder to understand for
> brogrammers (especially for beginners), whereas the benefit for users
> would be minimal.

I don't think that this proposal makes scripts any harder to understand 
for programmers than things are currently.  From a programmers 
perspective, they would still use variables the same way they currently 
do.  The only difference is that a user might not be using redef to 
change values, but the programmer doesn't see that happening anyway.  It 
also doesn't change anything about what configuration values the 
programmer makes available since the programmer is already forced to 
expose their configuration through the export section.

>> Invariably, there will be variable names chosen within software that
>> will be short and convenient or long and explanatory but may not end 
>> up
>> being just right if someone simply wants to configure a behavior.
>
> I think that would just be bad coding style.

That's a fair statement.  In an ideal world, all programmers would name 
their variables perfectly.  I know that the opportunity for poor naming 
is still present with the &config attribute value, but for me at least, 
it puts me in a different frame of mind because this is the name that 
I'm exposing to users as a configuration option.  It almost forces 
people to step out of the programming mentality.

> So that is definitively a valid point! But instead of coming up with a
> "new language element" I would prefer to add support for multi-level
> namespaces into Bro.

Yes, please do this! :)

> That all said, what's about the poor users? Instead of throwing a huge
> config file of key-value-pairs at someone who does not know about the
> internals of the corresponding scripts, I would provide a UI to them
> (maybe someone comes up with a bro-package...). The UI could display 
> all
> options in a structured way and further support configuration by also
> showing the corresponding documentation for each option. This would
> allow a clean cut between users and brogrammers without intermingling
> both worlds.

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.

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".

Sometimes abstraction like this isn't warranted, but I think it has to 
be done here.  Bro needs to turn into a platform that treats users as 
first class citizens in the community and we need to acknowledge that 
there will be a day that they won't be reading script source code and 
they won't want to be exposed to programmer-isms.

   .Seth

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