Re: [Bro-Dev] Configuration framework syntax proposal

On 22 Sep 2017, at 16:26, Jan Grashöfer wrote: >> module Foo; >> >> export { >> >> ## The username for our new feature. >> ## >> ## Display: User Name >> option user_name: string; >> >> } > > I really like that syntax! I agree. That looks really nice! .Seth -- Seth Hall

Re: [Bro-Dev] Configuration framework syntax proposal

> module Foo; > > export { > > ## The username for our new feature. > ## > ## Display: User Name > option user_name: string; > > } I really like that syntax! I think Jon is right regarding the semantics that the "const" keyword implies (I missed that in my first mail).

Re: [Bro-Dev] Configuration framework syntax proposal

I like that - I honestly did not really like configopt from the beginning, the only reason for choosing it is that "config" conflicts with the input/logging framework. I am not completely sure we should deprecate const - there might actually be a need for constants that can really only be

Re: [Bro-Dev] Configuration framework syntax proposal

I was thinking the same when discussing an earlier proposal with Johanna. The "configopt" idea came out of that with the observation that "const " isn't quite fitting here (and, as you say, it's already blurred anyways). At that time, however, the thinking was still to have a 2nd namespace, and

Re: [Bro-Dev] Configuration framework syntax proposal

> On Sep 21, 2017, at 11:50 AM, Johanna Amann wrote: > > The feature that the > configuration feature wants to bring is the ability to change options > during runtime - which cannot be accomplished with redefs. redef-able > consts will still have their place afterwards

Re: [Bro-Dev] Configuration framework syntax proposal

I just wanted to note that after keeping up on this thread that I agree with those same points. :) .Seth On 21 Sep 2017, at 12:50, Johanna Amann wrote: >> I think that it's important to have this behavior come with a >> reasonable >> default. I think that whatever we choose should just

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

Re: [Bro-Dev] Configuration framework syntax proposal

On Wed, Sep 20, 2017 at 10:00:33PM -0500, Daniel Thayer wrote: > On 9/20/17 5:24 PM, Johanna Amann wrote: > > advantages or disadvantages. One idea is to have a different syntax to > > define > > the configuration option. Instead of > > > > const filter = "ip" ="input.pcap.filter"; > > > > the

Re: [Bro-Dev] Configuration framework syntax proposal

On 9/20/17 5:24 PM, Johanna Amann wrote: > advantages or disadvantages. One idea is to have a different syntax to define > the configuration option. Instead of > > const filter = "ip" ="input.pcap.filter"; > > the definition could look like > > configopt filter = "ip"; > If we decide to use

Re: [Bro-Dev] Configuration framework syntax proposal

On 20 Sep 2017, at 20:19, Johanna Amann wrote: > technically - yes. Though I am not quite sure that I like it :). 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

Re: [Bro-Dev] Configuration framework syntax proposal

> Could the definition be > > const filter = “ip” > > if you just wanted to use NameSpace::filter ? That kinda seems like the best > of both worlds… Especially if anything marked was automatically > registered as a configuration variable. technically - yes. Though I am not quite sure that

Re: [Bro-Dev] Configuration framework syntax proposal

> On Sep 20, 2017, at 6:24 PM, Johanna Amann wrote: > > > const filter = "ip" ="input.pcap.filter"; > > the definition could look like > > configopt filter = "ip"; Could the definition be const filter = “ip” if you just wanted to use NameSpace::filter ? That kinda

[Bro-Dev] Configuration framework syntax proposal

Hello bro-dev, in this email I want to get feedback on a possible syntax for the configuration framework. The aim of the configuration framework is to provide an easy method for Bro users and script writers to change configuration options during the runtime of Bro (as opposed to only on startup