[Bro-Dev] Dynamic plugin model (Re: [Bro-Commits] [git/bro] topic/robin/dynamic-plugins-2.3: Start of a plugin writing how-to. (87a1618))

[Robin Sommer]

On Thu, Dec 19, 2013 at 10:23 -0500, you wrote:

> * Would a section on testing be appropriate?  Both btest and unit
> testing might be useful for plugins.

Ack, that's a good point, the init-plugin script could put a basic
setup in place for that, maybe even with a first test making sure
things compile.

> * A short section explaining how / when to modify CMakeLists.txt might
> be useful.

Yeah, likewise agreed. Indeed tthe documentation needs quite a bit
more material to get people actually started without having to browse
a ton of other code first. I'll leave that for later though once we've
fleshed this all fully out.

> * Should plugins be allowed to link to additional libraries?

Yes, definitly. My thinking is that the plugin author will extend the
CMakeIndex.txt with the corresponding pieces, including compile-time
logic to figure out if it's available. However, if the binary module
aims to link against a lib that's not available at runtime where Bro
executes, then I don't think there's much more we can do than fail
loading the plugin: the dlopen will fail (iirc, Bro currently aborts
in that case, I'm not sure if it should proceed without?)

Thanks for the feedback. From chatting with Seth the other day, I took
two more suggestions away:

- I'm coming around that the BRO_PLUGIN_* macros aren't the best way
  of doing things. My main motivation for using them was hiding
  implementation details of the plugin API so that we can more easily
  change things without breaking existing code. However, it seems they
  are putting too much constraints on the plugin writer and/or, if one
  needs to get around them, require a lot of digging into the
  internals. So I'm mulling over creating a (simpler) C++ API to the
  Plugin class that can be used directly.

- The static and dynamic plugins could be unified further. It's 
  unclear what the right default is for shipping plugins that provide
  standard functionality, but it would be nice in any case if we could
  just flip a switch to change between static and dynamic builds for
  the in-tree stuff.

Robin


-- 
Robin Sommer * Phone +1 (510) 722-6541 *     robin at icir.org
ICSI/LBNL    * Fax   +1 (510) 666-2956 * www.icir.org/robin