[Bro-Dev] Configuration framework syntax proposal

[Jan Grashöfer]

On 21/09/17 03:30, Seth Hall wrote:
> I also don't like it.  I think with this proposal there is some
> recognition that our community has separate and distinct parts (and some
> overlap between them).  The people that program Bro scripts and the
> people that use Bro scripts.  I feel like there are benefits to getting
> a chance to separate the notion of configuration away from the notion of
> programming.

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.

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

> There's also the problem of single level namespaces which will limit the
> expressiveness and depth that you could possibly give through
> configuration keys.

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. As the Bro language is already quite extensive, I 
think that every new syntax, which does not follow the already existing 
concepts, reduces usability. That's also why I would choose &config 
instead of configopt.

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.

Jan