[Bro-Dev] CBAN design proposal

[Siwek, Jon]

> On May 23, 2016, at 4:59 PM, Robin Sommer <robin at icir.org> wrote:
> 
>> That would make life easier for authors, and that’s maybe even a
>> higher priority than maximizing the quality/consistency of user
>> experience because, without authors, there won’t be much for users to
>> experience in the first place.
> 
> Yeah, that's exactly what I'm advocating: making it easy should really
> be priority number one, with everything else coming second. If you see
> ways to adapt the design to target that specifically, I'm all for it.

Yeah, I have ideas, but seems like there might be another day of some discussion before I try to formally reframe a design doc. Here’s the direction I'm thinking:

- still have a "bro/cban" github repository, but it now contains git submodules that point directly to other github accounts/repos

- the initial submission process involves doing a pull request on the bro/cban repo where the only change made is the addition of a submodule.  These merges probably can be automated, but if a human were to do it, I’d expect it wouldn’t be a time-consuming task — just check if the change is adding a submodule and then click a button to merge (don’t even have to look at the contents of the submodule).

- a person that has submitted something to cban needs no further interaction with it and they resume their typical development workflow — cban client's “update” command will fetch/pull directly from their git repo.

- all submodules get scanned by an out-of-band nightly process which checks for brokenness and other quality metrics

- submodules that are found to have never been in a working state are auto-removed (or could initially be a task that’s not a big deal for a human to do every so often if metrics of brokenness are consistently available)

- it’s not a big deal for a submodule to temporarily enter in to a broken state — cban users can always roll back to a previous version or just uninstall it.  It’s up to the community to communicate/collaborate directly w/ the author here to get things fixed.

- metadata associated w/ plugins is all optional, but its existence contributes to some arbitrary “quality” rating/metrics

- metadata logically can be categorized in two types, one type is related to discoverability (tags, author, license, etc) and one type is related to interoperability (version number, dependencies)

- discoverability metadata is aggregated during the nightly quality check processes and automatically commits that information to the “bro/cban” repo.  Without doing this, I think cban clients would have an incredibly slow “search” command that goes out to each submodule individually and gathers metadata.  (features related to discoverability might be lower priority in general)

- interoperability metadata can also be aggregated nightly along the discoverability metadata, but when the cban client is actually going to perform specific operations on a particular submodule, it gets this data directly from the cloned submodule(s) to make sure the info is up-to-date.  Version numbering can probably be done via git tags, but dependency info stored in a canonically named text file.

I think all those points make things easy on contributors, minimize direct involvement of the Bro Team in sorting out problems related to particular plugins, and provide a useful way for users to discover and maintain Bro plugins.  There’s more potential for users to encounter broken/bad plugins, but maybe that also encourages stronger community involvement w/ users more likely to try and help get problems resolved.

- Jon