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