<div dir="ltr"><div><div><div><div><div><div><div><div>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.<br><br></div>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!<br><br></div>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:<br><br></div>> const user_name: string &redef<br><br></div>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.<br><br></div>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.<br><br></div>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: <a href="https://forge.puppet.com/puppetlabs/mysql/types">https://forge.puppet.com/puppetlabs/mysql/types</a> This would be pretty easy to do with the Broxygen documentation, and a UI could also expose this.<br></div></div><div><br></div><div>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.<br><br></div> --Vlad<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 21, 2017 at 10:22 AM, Robin Sommer <span dir="ltr"><<a href="mailto:robin@icir.org" target="_blank">robin@icir.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On Thu, Sep 21, 2017 at 14:51 +0000, you wrote:<br>
<br>
> comments. Like Jan, I had a hard time understanding the benefit having<br>
> two names for the same value: the identifier and config string.<br>
<br>
</span>Yeah, that's been my original concern as well. What if we focused that<br>
new attribute just on displaying something to the user:<br>
<br>
const user_name: string &redef &display_name="User name"<br>
<br>
A UI would show it as "User name", but everything else (incl.<br>
internally the configuration framework) would use<br>
My_Program::user_name. This would even work more generically, anything<br>
could have a &display_name and we'd have Broxygen pick up on it too.<br>
<span class="HOEnZb"><font color="#888888"><br>
Robin<br>
<br>
--<br>
Robin Sommer * ICSI/LBNL * <a href="mailto:robin@icir.org">robin@icir.org</a> * <a href="http://www.icir.org/robin" rel="noreferrer" target="_blank">www.icir.org/robin</a><br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
bro-dev mailing list<br>
<a href="mailto:bro-dev@bro.org">bro-dev@bro.org</a><br>
<a href="http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev" rel="noreferrer" target="_blank">http://mailman.icsi.berkeley.<wbr>edu/mailman/listinfo/bro-dev</a><br>
</div></div></blockquote></div><br></div>