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 _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
