[Bro-Dev] Configuration framework syntax proposal

[Vlad Grigorescu]

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 that this
feature is where those two groups intersect. While a lot of thought has
gone into what this looks like from an end-user perspective, I want to make
sure that we also make this easy and elegant from a developer's
perspective. Bro scripting already has a high barrier of entry, and I think
that we need to be careful not to raise that barrier further. As was
discussed during BroCon, I think that the Bro community is increasingly
relying on developers outside of the core team to contribute scripts -- and
that's a great thing!

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 &redef

At the end of the day, what we're discussing is how a developer should
document and expose a feature to an end-user. If, as a developer, I choose
a bad variable name, then I'm not providing a good experience for the
end-user, but that's my decision. I don't think that forcing developers to
essentially add documentation via syntactic sugar is the right approach. If
their variable names are confusing, people are less likely to use their
script.

I think that a lot of what users might want to re-configure is too complex
to be explained through a variable name anyway. We already have a system in
place to document variables, and I think that we need to rely on that
instead of focusing so much on which name is exposed to the user.

As we look at moving Bro scripts to packages, I think we need to look at
how other package repositories have handled similar configuration options.
Puppet Forge, for instance, has a types tab which documents the names of
the parameters, and what they do:
https://forge.puppet.com/puppetlabs/mysql/types This would be pretty easy
to do with the Broxygen documentation, and a UI could also expose this.

tl;dr version: I want to find something that makes life easy for both
developers and end-users, and I think we already have the documentation
mechanism in place to be more expressive about variables.

  --Vlad

On Thu, Sep 21, 2017 at 10:22 AM, Robin Sommer <robin at icir.org> wrote:

>
>
> On Thu, Sep 21, 2017 at 14:51 +0000, 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 something to the user:
>
>     const user_name: string &redef &display_name="User name"
>
> A UI would show it as "User name", but everything else (incl.
> internally the configuration framework) would use
> My_Program::user_name. This would even work more generically, anything
> could have a &display_name and we'd have Broxygen pick up on it too.
>
> Robin
>
> --
> Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin
> _______________________________________________
> bro-dev mailing list
> bro-dev at bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20170921/28d14300/attachment.html