topic/robin/reader-writer-plugins

Description

This moves log writers and input readers to the new plugin API. No functional differences, except that one can now implement them via external plugins as well. Test cases for that included.

Most of the change is just moving stuff around, plus adapting to the new API. There are a few changes to defining/handling of the corresponding builtin types, as they now have to be dynamic.

Environment

None

Activity

Show:
Seth Hall
August 4, 2014, 5:39 PM

I think that script and any tests (assuming the plugin test infrastructure is in place?) need to move into the plugin. Once functionality is removed from the Bro core, all bits and pieces of that functionality need to move as well. I'm just worried that if we don't make this a pretty hard rule that we'll slip a little bit and allow bits of plugins to remain in the Bro core.

Robin Sommer
August 14, 2014, 10:52 PM

Next attempt. Branch topic/robin/reader-writer-plugins in bro, bro-aux, and cmake; plus a new repository bro-plugins (master branch there).

Per discussion on the mailing list, I've moved DS and ES into their own repository. I've also committed some further tweaks to plugin skeleton setup, including a simple configure template that makes it easier to pass further options (like for DS, where the DS libraries are installed).

Jon Siwek
August 21, 2014, 6:12 PM

Quick questions about the bro-plugins repo:

There's directories called elasticsearch/scripts/Bro/ElasticSearch and dataseries/scripts/bro/dataseries. Should the capitalization be more consistent? If so, which casing scheme should I go with?

elasticsearch/scripts/Bro/ElasticSearch/main.bro is an empty file. Is it meant to contain something, or can I just remove?

Robin Sommer
August 21, 2014, 6:51 PM

Yeah, should be consistent, but looks like I couldn't make up my mind
which version I prefer.

The skeleton puts the capitalized version in place, and I think that's
indeed my preference, as it matches the plugin's name directly. On the
other hand, that doesn't align with our current naming scheme for
scripts, so it would put a new standard in place for plugins (which
might be fine and indeed help to differentiate their scripts).

I guess in the end I'm fine either way; do you have a preference?

Just remove.

Jon Siwek
August 21, 2014, 7:48 PM

Also no preference, will choose the capitalized version maybe just because that's the one that requires less changes.

Assignee

Jon Siwek

Reporter

Robin Sommer

Labels

None

External issue ID

None

Components

Fix versions

Affects versions

Priority

Normal
Configure