[Bro-Dev] CBrAN Bro Control Plugin

[anthony kasza]

Having a name for a directory resembling "repo" when the directory is
not a repository is confusing, I agree. I'll refer to it as a package
moving forward.

The project page refers to the package manager as CBAN, let's go with that.

Having a flat file representation of the universe would make managing
the universe through GitHub much simpler. It would also save people
from having to write a bunch of SQL code.
My thought was for the universe database to contain the following
pieces of information (taken from the project page): name, URL,
author, tags, package version, Bro version, dependencies, license,
description. If a plain text flat file is used would would it be
useful for the file to be readable by the input framework?

-AK

On Mon, Oct 14, 2013 at 3:20 PM, Siwek, Jonathan Luke
<jsiwek at illinois.edu> wrote:
>
> On Oct 14, 2013, at 11:43 AM, anthony kasza <anthony.kasza at gmail.com>
>  wrote:
>
>> My initial thought was for the Bro project to maintain and distribute a SQLite database of rebros (git repos of Bro scripts).
>
> A terminology nitpick: a "rebro" (according to the proposal doc) isn't a git repo, but a git repo may contain rebros (directories containing a __load__.bro script).
>
> I'm only pointing it out to suggest the first step is that we come to a consensus on what terms to use to describe things else later discussion might get confusing.
>
> Here's things I think need naming:
>
> 1) A git repository that may contain bro scripts.
>
> I actually don't think these need a special name, just call it a  "repo" or "repository" as usual since there's not really any unique requirements.
>
> 2) A directory containing __load__.bro.
>
> These just let Bro "@load <dir>".  "rebro" is confusing for this, since it's not a git repo itself.  I've always called this a  "package" for lack of anything better.
>
> 3) CBrAN
>
> Don't think this was actually decided?  Works for me, except the case switch in the middle is a bother.
>
>> As Python2.5+ has native support for SQLite this would not require users to install additional Python modules. A community developer would be able to register his/her rebro for inclusion in the SQLite file distributed with broctl. The SQLite file would represent the universe referred to on the project page.
>
> If the registration process were to be something simple like a person doing a pull request on GitHub where they've added their repo to the "universe" database, a flat file rather than SQLite might be better for that database file since it should be easier to change and audit (by just looking at the git commit) ?
>
> Though if BroControl parses that file and generates some internal representation that may use SQLite, that might be one way to do it.  Were you mostly thinking of storing metadata/dependency stuff there?
>
> - Jon