On Sun, Feb 05, 2017 at 22:04 +0000, you wrote:
> I understand the argument that the old semantics (manager not running > log events/filters) may be more performant, though, I’d consider > whether the internal comm. framework or the base/user scripts should > be the one to decide. I agree that generally it'd be nice to be able to do it either way. However, I'm pretty sure at this point that we need the separate high-performance path that the old communication introduced, for the reasons discussed in this thread and also for consistency. I'm working on adding that code, and I think it should be the standard model, just as it is currently. In addition to that, one can always send log_* events around and then do custom processing on the receiving side. That's not quite as transparent as "normal" log messages would be with their configuration and filters, but that might actually be a good thing: if we actually had both mechanisms (sender- and receiver-side filtering) built transparently into the logging framework, it could end up being quite confusing what's used when. I propose that for now we make Broker work like the current model, and then we go from there. If we need more, we can add that later. The less semantic differences we have between old and new communication, the easier the switch will be. Robin -- Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev