> On Jun 6, 2016, at 1:50 PM, Robin Sommer <ro...@icir.org> wrote:
> 
> - For shipping scripts:
> 
>    - We simply add <install-base> to Bro's BROPATH. That means one
>      can now put "@load <name>" into local.bro and Bro will look for
>      a __load__.bro inside the top-level container directory. That
>      file can do whatever it wants for loading further scripts
>      located anywhere inside the container. One can also load
>      individual top-level scripts that way through "@load
>      <name>/foo.bro”.

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?

I was thinking there’s a directory full of scripts from containers and Bro 
automatically loads all of them.  If a user did “cban install <name>” then that 
container’s scripts are all auto-loaded.  But if a user did “cban unload 
<name>” then they are free to still manually load scripts from it, but 
otherwise it’s not auto-loaded.  They can then do “cban load <name>” to switch 
back to a default load-everything behavior.

> - In addition, we believe we should go back to require that minimal
>  set of meta information that we discussed earlier: a container would
>  need at least a name, a contact, a version, and a license.

Is that metadata a requirement for submission to the community repo or just for 
general interoperability with the container manager client?

From user perspective, the later may be fine except potentially in the use-case 
where a person has no plans to submit their container in the near-term, but 
want to use the manager client and the container structure maybe for sake of 
consistency or other reasons?

The other potential problem is if you require metadata and then call that 
container a “package”, we are back to the issue of me needing to know what to 
do about the current use of the term “package” which refers to a collection of 
scripts that require no metadata.  A “package” can't require metadata and also 
not require it at the same time.

If it doesn’t confuse users to rename the current “package,” that seems like an 
ok path to go forward with.  A rename may at least temporarily confuse/bother 
me because I’ve used the term  “package” consistently in the past, but I’m not 
a user myself and don’t know whether the usage is common among actual users, so 
I need someone else to decide.

- Jon

_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Reply via email to