On Tue, Jan 30, 2018 at 9:38 AM, Robin Sommer <ro...@icir.org> wrote:
> An attribute can work if we're confident that the relevant information > can always be extracted from the event parameters. In a concurrent > prototype many years ago we instead used a hardcoded set of choices > based on the underlying connection triggering the event (5-tuple, host > pair, src IP, dst IP). So you'd write (iirc): > > event protocol_event_1(c: connection ...) &scope = connection > > That detaches the context calculation from event parameters, with the > obvious disadvantage that it can't be customized any further. May be > there's some middle ground where we'd get both. Yeah, it seems open to having multiple methods available for the user to choose from: dynamic call to script-land, dynamic calculation in core (select from predefined list), or even a static value (not that I can think of a particular place that would actually use that right now). Was there more benefit of using the predefined choice than saving the overhead of calling out to script-land to do the context calculation? - Jon _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
