> On Jun 6, 2016, at 4:55 PM, Robin Sommer <ro...@icir.org> wrote: > > 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).
So scripts do not autoload, but plugins do? I’m thinking the procedure a user takes to get things working should be the same regardless of script-only vs. binary plugin. And if the process isn’t the same in both cases, is that also in conflict w/ the goal of a developer being able to promote a script-only thing into a binary plugin without users noticing? > 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? I was thinking that Bro command line and BroControl would have to work similarly. So it may be Bro needs a direct change to how it handles auto-loading everything within a directory, either hardcoded specifically for use with the new containers or else a path specified by a new environment variable? >> 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". :-) I agree that plugin no longer matches this design when referring to top-level container. And package maybe has less severe conflicts than before, but I'd still need some clarification in how to use it within code/docs. If package is still desirable, then maybe try to silently change current usage of “script packages” into just “scripts” without a new container name at all for them. I also suggest “script directory” as a potential name if needed. Then reappropriate “package" for use in this new project. To mock up example documentation: " The Bro Package Manager is a tool that makes it easy for Bro users to install and manage third party scripts and binary plugins. It does this by providing both a communal GitHub repository where developers contribute packages they have created and a command line tool, ‘bro-pkg', for users to fetch packages from that repository. The packages that users submit may contain either scripts or binary plugins for Bro and the command line client automatically handles their installation process and interdependencies with other packages. To create a package, a developer needs to 1) Create a directory and metadata file with the following required fields... (TODO: details) 2) For packages that just contain Bro scripts, see the following docs about Bro’s script loading process (TODO: there’s maybe not a good doc on the script loading process besides [1] and [2], so maybe need a better one) and then fill out these additional metadata fields... (TODO: details) 3) For packages that contain binary plugins for Bro, see the following docs about plugins: [3]. Then fill out these additional metadata fields... (TODO: details) 4...) (TODO: get into submission process, maybe talk about btest for unit tests and other ways to improve package quality ratings, etc) “ That all looks consistent except part (2) ends up pointing people toward existing docs/examples that reference “package” but with a different meaning. I'd need a decision to be made about how/whether to change that. If people are happy w/ the new design proposal and ready to revisit naming, it may be helpful to plug in (pun intended) their ideas for naming the project/client/containers as substitutes for what I used in the above example or make a new, similar one and read it through to see if it’s still coherent. - Jon [1] https://www.bro.org/sphinx/script-reference/packages.html [2] https://www.bro.org/sphinx/scripting/index.html [3] https://www.bro.org/sphinx-git/devel/plugins.html _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
