> On Feb 6, 2017, at 10:43 AM, Robin Sommer <ro...@icir.org> wrote: > > 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.
Yeah, I agree that it should behave the same. Was just also trying to reframe the problem to give ideas for solutions that give back old semantics (i.e. via script-level mechanisms). No big deal, since there’s no demand for it. > 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. It was actually always confusing to me that a remote log entry versus a local log entry would be processed differently regarding the log_* events. The event is a property of the Log::Stream definition and the logging API or docs don’t distinguish between outgoing versus incoming log entries there, or do they? Or is a Stream meant to be thought of from only the perspective of an outgoing sequence of log entries? Could be I misunderstood the log framework the whole time, and that’s why broker behaved the way it did :) - Jon _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
