[Bro-Dev] CBAN design proposal
Robin Sommer
robin at icir.org
Thu May 26 08:46:13 PDT 2016
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
More information about the bro-dev
mailing list