[Bro-Dev] CBAN naming

[Matthias Vallentin]

> 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? 

This scenario seems to be well supported with the "container" layout
that Robin proposed. Since each package/plugin will remain in its own
prefix, it can easily start with a script and later on morph into
full-blown shared library plus a set of bifs.

If we consider everything a self-sufficient container, then even the Bro
base is just one of them. (Certainly a very special one, since it
provides the most functionality.) That reminds of BROPATH. If we loosen
up its semantics, it would refer to a set of prefixes where to search
for containers. For example, consider the following containers:

    /usr/local/share/bro/base
    /usr/local/share/bro/policy
    /usr/local/share/bro/site
    /opt/bro/github-user-foo/bro-fancy-detector
    /opt/bro/github-user-foo/bro-string-algs
    /opt/bro/bar/bro-deep-faf

This would result in the following set of "search paths:"

    /usr/local/share/bro
    /opt/bro/github-user-foo
    /opt/bro/bar

> 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. 

Ideally, it doesn't matter from a user perspective whether a plugin is
script-only or ships with shared libraries and bifs.

> I believe that any issues with the name of "plugin" versus "package" can
> and will be quickly cleared up when the project is released. 

Yeah, I think either would work. One more thing: we should avoid the
term "container" because there's an entire community emerging where this
term means something very different. I don't think anyone ever proposed
"container" to end up in the terminology, just making sure we're not
going down that road.

    Matthias