[Bro-Dev] New proposal (Re: CBAN naming)

[Siwek, Jon]

> On Jun 6, 2016, at 1:50 PM, Robin Sommer <robin at 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