Re: [Bro-Dev] Configuration framework syntax proposal

> 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 I agree; note that what I proposed

Re: [Bro-Dev] Configuration framework syntax proposal

> On Sep 21, 2017, at 10:37 AM, Johanna Amann wrote: > > The only thing that I would like to avoid (which is obviously separate > from this) is internally remapping variable names to configuration names > in a non-reversible manner; then one suddenly has to think about

Re: [Bro-Dev] Configuration framework syntax proposal

First of all, thanks to Johanna for getting this discussion going, and thanks to everyone who's weighed in so far. I'm really excited to see this feature in Bro, and I'm also happy to see how much interest this has already garnered. To extend what Seth said about our two user groups -- I think

Re: [Bro-Dev] Configuration framework syntax proposal

On 21 Sep 2017, at 9:10, Siwek, Jon wrote: >> On Sep 21, 2017, at 10:37 AM, Johanna Amann >> wrote: >> >> The only thing that I would like to avoid (which is obviously >> separate >> from this) is internally remapping variable names to configuration >> names >> in a

Re: [Bro-Dev] Configuration framework syntax proposal

On Thu, Sep 21, 2017 at 02:57:31PM +, Siwek, Jon wrote: > > > I'm not sure how exposing something like "input.pcap.filter" is any > > different from exposing something like "Pcap::filter" from that standpoint. > > Maybe there's a larger discussion here around what the user experience > >

Re: [Bro-Dev] Configuration framework syntax proposal

On Thu, Sep 21, 2017 at 08:22:23AM -0700, Robin Sommer wrote: > > comments. Like Jan, I had a hard time understanding the benefit having > > two names for the same value: the identifier and config string. > > Yeah, that's been my original concern as well. What if we focused that > new attribute

Re: [Bro-Dev] Configuration framework syntax proposal

On Thu, Sep 21, 2017 at 14:51 +, you wrote: > comments. Like Jan, I had a hard time understanding the benefit having > two names for the same value: the identifier and config string. Yeah, that's been my original concern as well. What if we focused that new attribute just on displaying

Re: [Bro-Dev] Configuration framework syntax proposal

> I'm not sure how exposing something like "input.pcap.filter" is any different > from exposing something like "Pcap::filter" from that standpoint. Maybe > there's a larger discussion here around what the user experience should look > like? I feel like two different things are being talked

Re: [Bro-Dev] Configuration framework syntax proposal

> On Sep 21, 2017, at 8:18 AM, Seth Hall 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

Re: [Bro-Dev] Configuration framework syntax proposal

> On Sep 21, 2017, at 9:18 AM, Seth Hall wrote: > > 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

Re: [Bro-Dev] Configuration framework syntax proposal

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

Re: [Bro-Dev] Configuration framework syntax proposal

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