[Bro-Dev] libbroker status/plans

[Robin Sommer]

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
>  version).

Agree.

Robin

-- 
Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin