[Bro-Dev] CBAN naming

[Vlad Grigorescu]

Having reread through the discussion, I want to try to take a step back and
review some of it.

I believe there are two goals in play:

1) From a user's perspective, the principle of least astonishment. Names
matter, and choosing something intuitive or familiar means we're not
raising the barrier to entry for a new user.
2) From a developer's perspective, submitting to "CBAN," maintaining and
updating their code should be as painless as possible. Let's not forget
that at the end of the day, the only thing that matters in making this
project successful or not is developer contributions. If people aren't
contributing, none of this has any point.

The first goal is the reason we moved away from bags and carts. However, I
think we're in danger of straying too far away from the second goal. I
think having containers which manage both scripts and plugins would be a
mistake.

A scenario that I see as being quite likely is that a developer starts such
a container as being script-only, but wants to expand it at some future
date. Say there's some new botnet with a domain-generation algorithm that
they would like Bro to predict and alert on. The script is functional, it's
being deployed, but it has a noticeable performance impact. After some
refactoring, the developer adds a BIF to do some string-formatting heavy
lifting in C++ instead of in script-land. At this point, how does the
script package get converted to a plugin? Is this a new container? Is it a
refactoring of the existing container? Will bro-pkg be smart enough to
remove the old scripts from the script package and make sure the scripts
from the plugin are being loaded?

I fear that in trying to reduce confusion over nomenclature, we're
complicating the design and introducing much more confusion. I believe
there are advantages to having script-only plugins. Easier iterative
development is one, but also having a well defined structure with a clear
place for btest (in fact, init-plugin even creates a simple btest when
creating the plugin).

I believe that any issues with the name of "plugin" versus "package" can
and will be quickly cleared up when the project is released. I'll note that
the script plugin component is actually the only one currently documented
here: https://www.bro.org/sphinx-git/devel/plugins.html

I also think that since many of our developer audience is on this list, and
we've been spamming them about this for the past 10 days, our user outreach
has already happened. :-)

  --Vlad

On Sun, Jun 5, 2016 at 5:26 PM, Siwek, Jon <jsiwek at illinois.edu> wrote:

>
> > On Jun 5, 2016, at 11:51 AM, Slagell, Adam J <slagell at illinois.edu>
> wrote:
> >
> > Regardless, it seems that you and Jon have irreconcilable differences
> that eliminate plugin or package. And as the PI and implementer, I give
> high weight to both of your opinions. Would either of you object to
> extensions?
> >
> > So while I *really* hate to do this, I will throw out bro-bee and Bro
> Extensions for Everyone.
>
> We haven’t had a lot of time to reconcile, but my stance is that it’s not
> logical to choose a project name that introduces ambiguity in the naming of
> the top-level containers it deals with.
>
> Some paths to move forward that I see:
>
> 1) revisit the design of what the top-level container is
>
> 2) use plugins as top-level container and project name that refers to
> plugins
>
> 3) use plugins as top-level container and project name that is totally
> unrelated to the container name
>
> 4) use plugins as top-level container, a project name that refers to them
> by a different name, and then suggest how docs should be written or
> re-organized to avoid ambiguity.  I’m only being slightly facetious here, I
> really would need extra help/effort with guidelines for what term to use in
> what situations.  e.g. is it ok to call it a “plugin” when referring
> directly to existing plugin docs, but I should use the other term
> otherwise?  Seems better to avoid the extra effort and strain this path
> puts on maintaining consistent/clear docs.
>
> - Jon
>
> _______________________________________________
> 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/20160606/87623cd5/attachment.html