[Bro-Dev] libbroker status/plans
robin at icir.org
Thu Oct 23 15:20:35 PDT 2014
On Thu, Oct 23, 2014 at 21:59 +0000, you wrote:
> patterns. But I wonder if prioritizing Bro integration over this may
> be more helpful — if we learn significant parts of the C++ interface
> need to change,
I can see that either way actually: doing the C interface could turn
up problems with the C++ structure as well. But I agree in terms of
priority: Bro over C.
> There’s already some unit tests for the C++ API that could be
> replicated in C.
What I meant was ensuring the two stay in sync. Say if we added a new
capability to C++, can we trigger somehow a test failure if we forget
to add it to C?
> Won’t BroControl require this?
I was imagining for 2.4 we'd leave the BroControl parts in place as
they are now, i.e., using the old comm framework. Were you planing to
replace that already?
> I started looking in to this a little and I’m thinking either LevelDB
> or RocksDB may be good default choices to use here.
(No experience with either, will take a look)
> If “receiver” means Broker versus The Internet
I was thinking about this case (the other current Bro does already as
well), but yeah, CAF certainly plays a part there as well.
> On RHEL6, looks like GCC 4.4.7 is the default, but all major C++11
> features I think appear in 4.8 and later
So maybe that means we'll need to wait another release at least before
making it mandatory, and giving people a heads-up that we plan to do
the switch. On the other hand, I would prefer to have it fully in
there right away, so that scripts can start to rely on it as soon as
possible. Tough call ...
> (I’m not sure it’s worth it to try and figure out what specific C++11
> features we can “get away with” and thus require older compiler
Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin
More information about the bro-dev