Great to see you're up for tackling this, it's one of the major missing pieces in the Bro world (universe? :).
I like Jon's terminology, and I agree that a flat file will probably work better than an SQL lite database for storing that meta information. I don't think the input framework needs to parse it, I picture all of this being handled outside of Bro itself (i.e., by BroControl). I actually need to go back to the project page to remind myself of the specifics there; it's been a while since that went up and we might want to update a few things. I'd be happy to chat sometime to flesh this out further. Robin On Mon, Oct 14, 2013 at 17:24 -0700, you wrote: > 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 > <[email protected]> wrote: > > > > On Oct 14, 2013, at 11:43 AM, anthony kasza <[email protected]> > > 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 > > _______________________________________________ > bro-dev mailing list > [email protected] > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > -- Robin Sommer * Phone +1 (510) 722-6541 * [email protected] ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
