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 * ro...@icir.org * www.icir.org/robin _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev