On Nov 5, 2012, at 2:13 AM, Vern Paxson <[email protected]> wrote: > Let's start with what's deficient about the current style. The overarching > problem is it's hard to understand/explain, correct?
Yep. > How much of this is > the funky [$pred...] syntax, vs. that we've wound up adding a bunch of > separate hooks into the framework so it's hard to know which hook to use, > and/or it's hard to understand what a given collection of hooks does? Personally, it's mostly the syntax. There are also some cases where it's hard to express what you want in a single policy item too. Some of this could probably be fixed within the notice policy now, but then we'd essentially be turning the notice policy into a set of functions which starts to look suspiciously similar to events being executed immediately without the familiar syntax of events. > I feel like we need to better determine just what problem we want/need to > solve in order to then think about how to coherently provide better support > for it. I suspect that the reason the notice policy mechanism was first created was due to need for immediately evaluated events. The event handling mechanism feels very natural in Bro after using it for a while and the existing notice policy ends up feeling weird because you have to do a lot of uncommon and unfamiliar syntax. I'm not completely tied to the "policy" keyword, but does it seem unreasonable to have something like this immediately executed event that we've been discussing? As -- 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
