On Nov 1, 2012, at 5:47 PM, "Siwek, Jonathan Luke" <[email protected]> wrote:
> It may be workable, but I think the latency does make things more complicated
> so it might not make sense to re-use this policy model for the file analysis
> framework, but that shouldn't be a showstopper for using it for notices. I
> think it's fine to have the policy models be inconsistent, as long as both
> are easy to understand and use for their purpose.
As we discussed earlier and I never brought up in my overview, would it be
better if we had some mechanism sitting between events and functions?
"Synchronous events"? "Multi-bodied functions"? Here's an example of how a
synchronous event might look at the script land…
global awesome: event(a: count) &synchronous;
global foobar: event(a: count);
event bro_init()
{
event foobar(1);
event awesome(5);
}
event awesome(a: count) &priority=5
{
print fmt("awesome: %d", a+5);
}
event awesome(a: count) &priority=2
{
print fmt("awesome: %d", a+2);
}
event foobar(a: count)
{
print "foobar handler!";
}
Assuming synchronous events existed, the output would be this:
awesome: 10
awesome: 7
foobar handler!
I would really kind of like to move away from this policy model. The more I
think about it, the less Bro-y it feels and I have trouble remembering how
exactly to use them too (which I don't think bodes well for anyone!). Focusing
on simplicity and consistency at the script layer is something that we'll
probably have to continue to struggle and fight for forever. Although, I'm
generally ok with complexity anywhere in Bro as long as we find a clear and
obvious way to expose it to users.
.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
