> On Jun 5, 2016, at 10:55 AM, Robin Sommer <ro...@icir.org> wrote: > >> To me, the important part of a the definition of a plugin for most >> software is that it is an externally contributed, self/contained >> add-on which extends functionality. > > Agree in principle, but "extending functionality" with a plugin is > different that just writing a new Bro script. A "plugin" typically > plugs into a set of hooks that a software provides to extend things it > doesn't provide out of the box; once loaded, that new functionality > then becomes a core feature just as if it had been built in in the > first place. I don't see, e.g., writing a script-level detector for > new vulnerability XYZ like that. If a wrote new Python module > implementing, say, BASE65 encoding, I wouldn't be adding a "plugin" to > Python either.
I think we are working from two different mental models. You are thinking of Bro mostly from the programming language perspective and analogies with Python. I am thinking of it as a tool or piece of software. It’s both, but I am not bothered by incongruencies to Python. 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. ------ Adam J. Slagell Chief Information Security Officer Director, Cybersecurity Division National Center for Supercomputing Applications University of Illinois at Urbana-Champaign www.slagell.info "Under the Illinois Freedom of Information Act (FOIA), any written communication to or from University employees regarding University business is a public record and may be subject to public disclosure." _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
