> 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 _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev