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
