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

[Robin Sommer]

So Johanna and I just white-boarded a somewhat more generic approach
that we believe would work well to cover the various use-cases without
hardcoding much in terms of structure at all.

The brief summary is that we would allow people to specify how to set
BROPATH and BRO_PLUGIN_PATH, and how to build their binary stuff; and
otherwise don't impose any furher structure on them, just some
defaults. 

Here's the idea in more detail:

- We stay with the model of a "container" that can carry both scripts
  and binary plugins. (We could now maybe go back to "package" again;
  but I'll keep using "container" in the following).

- The user's git repository *is* that container, however we don't
  enforce much of a layout on that at all, just some defaults they can
  change if desired. I'll call the disk location of the local clone
  for a user repository <repo>.

- At install time ("cban install" or whatever) <repo> gets copied into
  a subdirectory <name> at a global location <install-base> ("cp -rp
  <repo> <install-base>/<name>"). Uninstallation means removing that
  installation directory.

- 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".

    - If one wants to locate the scripts somewhere else inside the
      container, optional meta information can set a different BROPATH
      relative to the top-level directory. For example, to put them
      into "<repo>/scripts", one would specify as meta information
      "bropath=scripts".

- For shipping binary plugins:

    - Through meta information, we let the author specify a build
      command to build all their binary stuff, such as "./configure &&
      make && make test". The command line client runs that command
      inside <repo>.

    - Per default, we expect that build command to create a directory
      <repo>/build that contains a binary plugin. We add
      <install-base>/<name>/build to BRO_PLUGIN_PATH.

    - If one wants to locate the plugin elsewhere, optional meta
      information can set a different BRO_PLUGIN_PATH.  For example,
      to put it into "<repo>/compiled/cool_plugin", one would specify
      as meta information "pluginpath=compiled/cool_plugin".

- 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 licence. For the
  optional meta information described above, we preset defaults:

    bropath=.
    pluginpath=./build
    buildcmd=               # Empty means: nothing to build.

So, examples:

    1. A container with just a single script pulled in through "@load foo".

       <repo>/META
            name=foo
            version=1.0
            license=bsd
            contact=foo at .bar.com

       <repo>/__load_.bro
            event bro_init() { print "Foo!"; }

    2. A container with multiple scripts all loaded through "@load foo".

       <repo>/META
            name=foo
            version=1.0
            license=bsd
            contact=foo at bar.com

       <repo>/__load_.bro
            @load ./script1
            @load ./script2

       <repo>/script1.bro
            event bro_init() { print "Foo1"; }

       <repo>/script2.bro
            event bro_init() { print "Foo2"; }

    3. Same as (2), but the scripts now in a subdirectory scripts/:

       <repo>/META
            name=foo
            version=1.0
            license=bsd
            contact=foo at bar.com
            bropath=scripts

       <repo>/scripts/__load_.bro
       <repo>/scripts/script1.bro
       <repo>/scripts/script2.bro

    4. A binary plugin:

       <repo>/META
            name=foo
            version=1.0
            license=bsd
            contact=foo at bar.com
            buildcmd=./configure && make && make test

       <repo>/configure
       <repo>/src/*
       <repo>/tests/*

       (The skeleton that init-plugin creates works for this directly
       already, except for the meta information.)

    5. A binary plugin with different build command and location:

       <repo>/META
            name=foo
            version=1.0
            license=bsd
            contact=foo at bar.com
            buildcmd=build-all-my-stuff.sh
            pluginpath=compiled/cool_plugin

       <repo>/build-all-my-stuff.sh
       <repo>/<any-other-stuff-that-the-shell-scripts-needs>





-- 
Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin