On Mon, Jun 06, 2016 at 21:08 +0000, you wrote:
> Similar to Daniel’s question, is there a one time setup the user does > or they need to modify local.bro every time they install a new > container? In this case I was thinking modify local.bro. That said, I remember your "load"/"unload" now, that would indeed be an alternative. What let's me hesitate a bit about that is that it doesn't match how people interact with scripts currently. Right now they have to @load them explicitly (unless they are in base/, where however we don't expect user scripts). Also, how would this work when using Bro from the command line (in contrast to BroControl)? Would it still pull in all the modules that have been loaded through the client? Could that cause confusion because we wouldn't have a standardized setting anymore? Would there be a way to prevent it? > Is that metadata a requirement for submission to the community repo or > just for general interoperability with the container manager client? Mostly for submission, though local installation through the client would need some as well I think (the name[1] and the paths at least). But people could always run out out of their local clone directly by setting BROPATH and BRO_PLUGIN_PATH manually (which is probably a good way for development anyways). Johanna suggested that if we do something similar to init-plugin to create a skeleton container, it would just put a meta file in place with defaults for the small set of fields we require for submission, so it wouldn't be much of a hassle either way. [1] Actually this occurred to me while writing the earlier mail: I think we need to let people set the name rather than just using the git repository name (which I at least had in mind so far). They may want to name their repository differently then what's the container should be called. > The other potential problem is if you require metadata and then call > that container a “package”, I'm not attached to using "package". "bundle" works for me as well, as I think "container" does (though Matthias has a point there about meanings uses of "container"). I just don't like "plugin". :-) Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev