[Bro-Dev] changing Notice::policy mechanism

Seth Hall seth at icir.org
Fri Nov 2 12:09:17 PDT 2012

On Nov 2, 2012, at 12:38 PM, Robin Sommer <robin at icir.org> wrote:

> Can't say I like the multi-body functions;

Continuing the discussion from the group call, I think that we're starting to converge on adding a "policy" keyword to the language to represent something between a function and an event.  Jon and I chatted about it some more and we couldn't come to a more abstracted and still clear keyword than "policy". (I really like the policy keyword here)

As a concrete example of the existing policy mechanism in the notice framework and the reworked mechanism I'll give an equivalent implementation of both.

# New style under discussion.
policy Notice::trigger(n: Notice::Info) &priority=5
	if (n$note == Whatever && Site::is_local_host(n$conn$id$orig_h)
		add n$actions[ACTION_BLAH];

# Existing style
redef Notice::policy += {
	[$pred(n: Notice::Info) = {
	 	return (n$note == Whatever && Site::is_local_host(n$conn$id$orig_h);
	 $priority = 5,
	 $action = ACTION_BLAH]

To address your various points about how this needs to work:

  1. Immediate policy handler execution.  Not even by jumping to the beginning of the
     event queue and waiting for the queue to be flushed, just direct execution. 

  2. Adding a "break"-like keyword to halt policy execution (only valid in policy handlers).

  3. No return value(s) when calling policy handlers.  We'll reuse the mutability mechanism
     that I subversively began using all over the place by modifying records in place.
     Calling policy handlers would look like this:
         policy Notice::trigger(n);

  4. Policy handlers sorted by priority.  Equivalent priority has undefined execution order,
     but I don't see that as a problem since it's already a concern for event handlers.


Seth Hall
International Computer Science Institute
(Bro) because everyone has a network

More information about the bro-dev mailing list