On Nov 2, 2012, at 12:38 PM, Robin Sommer <[email protected]> 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
--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
