(Sorry for the delay, I work only part-time. Many thanks for all the great input in such a short time!)
On Tue, Jul 7, 2009 at 17:41, Risto Vaarandi<[email protected]> wrote: > I'd recommend to take advantage of Jump and Options rules -- they have been > designed for arranging rulesets into hierarchies. Thanks, I'll look into it. Once I'm smart enough to ask questions, I will do so, unless I answer them myself by then (; >> (The major point of my email was the lack in documentation, though.) > > I will add a relevant sentence to the man page when the 2.5.2 release comes > out (it will add a feature to the Calendar rule and update its > documentation). Thanks again, I'm astonished by all the quick responses. And yes, of course, my choice of words for documentation might not have been perfect. (: On Tue, Jul 7, 2009 at 18:10, John P. Rouillard<[email protected]> wrote: > Also, you missed this section of the sec man page: > > Rules from the same configuration file are compared with the input > buffer in the order they were given in that file. When multiple > configuration files have been specified, each file containing a > distinct ruleset, events are processed virtually in parallel - the > buffer is always processed by all rulesets. Actually, I did see that. It goes on about how the config file names influence the final order of the output, and that is why i named my config files like I did in the first place. >>So, to help other newbies like me avoid this kind of problem, please >>please pretty please[0] add a hint to the "SUPPRESS RULE" section in >>the manual, like: > > Hmm, it applies to all rules, not just suppress so that's the wrong > place to put it IMO. A single rule that fired and supposedly disposed > of the event could still have the event matched by a rule in a later > ruleset. I was erroneously assuming that somehow other "laws" apply to rules creating output and rules suppressing output, because of the parallel processing above. Too many wrong assumptions and to few lines of code read on my part. But I still think that documenting the "only for the current config" part for suppress would be an improvement. > Perhaps a better place would be a caveat at the description of the > -conf command line parameter. I can't argue with that. (; >> To suppress those messages too, you have to move or copy your >> Suppress rules to these other configuration files. > > While that works, it's makes for a maintainance nightmare as the same > suppress rule is in multiple places. One other solution is to set up a > context based framework that allows rules to indicate that a > particular event was handled, and the other rulesets should ignore it. Yes, I was clearly overshooting there. Bad newbie, bad! > Such a framework is used/described at > http://www.cs.umb.edu/~rouilj/sec/. Rather than using suppress, it > would use: [...] Thanks for the pointer, I'll look into it. > [...] set up sec-10-suppress to act like a traffic cop and use it to > identify what ruleset a given event should go to. Then the sec-20 > sec-30.... rulesets would not be run by default (see OPTIONS RULE > procallin setting) on every event. [...] Rest assured, once i partially understand that voodoo, I'll return to you druids. (((: tty, 686f6c6d ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
