[Bro-Dev] CBAN design proposal

[Robin Sommer]

On Wed, May 25, 2016 at 17:59 +0000, you wrote:

> https://www.bro.org/development/projects/cban3.html

Looks great to me. Unsorted thoughts/notes:

- Let's keep BroControl integration in mind at leat. I agree that a
  standalone client makes most sense right now, but if there's
  something we can do that will make it easier for BroControl later to
  integrate, that's worth preparing for.

- One idea along those integration lines (BroControl and even
  elsewhere): would be nice to structure the client so that the main
  functionality resides in a Python module with a well-defined API.
  The client itself would then become just a small command-line
  frontend to that library.

- Where's that backend-side "out-of-band process" located? Is that
  part of the client as well? Or maybe at least part of that Python
  module? Would be nice to keep it easy to operate for CBAN-like
  repositories that people maintain externally.

- having both "upgrade" vs "update" commands sounds confusing, I'm
  sure I would constantly mix up the two. Suggest to rename one of
  them.

- What's the policy for namespaces (both script-land and plugin-land),
  and what's the relationship to the CBAN path? Should people use
  their GitHub name as namespace for their module? On the one hand
  that would be an easy way to avoid conflicts. On the other hand that
  makes forking difficult.

- Originally I wanted to suggest allowing more than one plugin per git
  repository but I really like the idea to leverage submodules, so I'm
  skipping that suggestion. :-)

- How do updating a plugin works now? If the author just updates the
  remote code, the submodules won't move, so is there an additional
  step there?

- Using a gist for meta data sounds good. We should then also have a
  nice permanent *.bro.org URL redirecting there so that we hide the
  actual location a bit for easier relocation.

- Any thoughts on distributing precompiled plugins? It would be nice
  if, say, I could just install the Mac version of plugin XYZ without
  having to compile it locally. The authors could optionally offer
  selected prebuilds for whatever platforms they want to support.
  Probably more a a feature for CBAN v2, but would be wort keeping
  mind how binaries would fit in.

- Another maybe-v2 idea: if a plugin listed its configuration options
  in a well-defined manner, tools like BroControl could pick up on
  that and offer a configuration UI without peopling having to write
  script code.

- Terminology 1: agree that we should find a better name for CBAN.

- Terminology 2: Using "plugin" as the entity name for everything is
  confusing I think, as right now I think most people understand it as
  something that gets compiled; nobody calls a script a plugin (unless
  it's a plugin for a specific script-framework; but that's even more
  confusing then :). The best alternative names I can come up with are
  "module" or "package", which are also overloaded already, but at
  least more generic. Other suggestions?

- We could create a public mailing list for CBAN for all discussions
  of individual plugins/modules, including in particular for decisions
  to remove something. Would be good to keep this all open and
  transparent.

- I'm offended that my plugin is just "nice", but Seth's is *cool*!
  
Robin


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