John P. Rouillard wrote:
> In message <[EMAIL PROTECTED]>,
> Risto Vaarandi writes:
>
>> John P. Rouillard wrote:
>>> In message <[EMAIL PROTECTED]>,
>>> Risto Vaarandi writes:
>>>> I have given it some thought and there are some at least some ways of
>>>> doing this. There could be a special command line flag (e.g., -conf2)
>>>> which loads a rule file, but doesn't use it for matching input lines by
>>>> default. Instead, a user could employ the 'jump' action to tell SEC to
>>>> use specific rule file only.
>>> That's probably the way I would go initially. Along with
>>>
>>> jump file [rulename or number]
>>>
>>> similar to how reset addresses individual rules. By default it would
>>> start at the first rule in the file. Alternatively a new rule type:
>>>
>>> type = label
>>> decription = a label to branch to.
>> After thinking a while, a separate rule type seems to be a better idea
>> (at least at the moment, maybe things will look yet again differently
>> after they have settled). At this moment I can think of the following
>> arguments that favor a separate rule type:
>> 1) many actions are triggered by a certain input line; however, that's
>> not always the case -- what is the semantics of 'jump' in the Calendar
>> rule, for example? The 'jump' rule type with a pattern, however, always
>> makes a jump for matching input lines,
>> 2) a jump rule always works faster than a jump action, because the
>> latter involves variable substitution which is sometimes a complex
>> operation.
>
> I wasn't advocating a jump rule, a jump action works, and doing
> variable substitution on the argument to the jump action could be a
> good thing. E.G.
>
> type=single
> pattern = ... (\w+) (\w+)
> action = jump rules_for_$1 $2
>
> where an input line looks like:
>
> tag ssh post_login ....
>
> so it will jump to the post_login section of the ssh rules file.
I can see that -- it's just the case that a separate rule type is faster
than action (there is no data structure copying and variable
substitution process which is expensive!). Also, actions are often
triggered not by input, but rather by a system clock. In the latter
case, what's the meaning of rule matching redirection?
>> I was thinking of virtual parallelism... this, of course, makes the
>> possible 'return' action semantics a bit more blurry, since in principle
>> the rule file processing order depends on the character order on your
>> system [...].
>
> Why? Return returns up the call stack. No ambiguity AFAICT. It gotbes
> to the rule with the jump action and continues processing from
> there. Now there may be a problem for actions after the jump.
Returning is not the problem here -- its result is fully determined and
always the same. I was rather trying to say that it is not determined
which rule files get processed and which don't during the jump. Suppose
you have files A.rules and a.rules, and 'return' is called from the end
of a.rules. When having LANG set to C, 'return' means that all rules
from both A.rules and a.rules get processed. When LANG is set to certain
flavors of UTF, only rules from a.rules get processed (because now a <
A!). However, if 'return' terminates only the processing of rules from
the current file, there is no ambiguity.
> E.G.
>
> action = jump a set_context_1; report context_1 "mail"
>
> in this case, I would expect the report to use the contents of
> context_1 as set by the rules executed by the jump. However there
> maybe some things (like command line context/variable substutions)
> that are done when the action is evaluated and not when the
> inidividual action is executed. E.G.
>
> action = jump a set_variable_f; report context_1 "%f"
>
> What value is substituted for %f? The value before the jump, or the
> value after the jump? I think it's the former but I could be wrong.
yes, % variables are substituted before the whole action list is executed.
>
>> There is a simple way around this possible ambiguity, though - one can
>> always write things down in a clear way by making jumps to individual
>> files
>
> Well that is always true right? The jump action taks an explicit label
> to determine what rule file to use.
...or rule files :)
>
> Compare this to:
>
> type=single
> description = 1-1
> pattern = .*
> action = jump a
>
> type=single
> description = 1-2
> pattern = .*
> action = jump a
>
> (in a)
>
> type=single
> description = a-1
> pattern = .*1$
> action = jump RETURN_STOP
>
> type=single
> description = a-2
> pattern = .*
> action = jump RETURN_CONTINUE
I understand... it is indeed shorter because you have one rule less (a
check for the so called "return result" from another rule set). However,
checking the end result explicitly in the calling ruleset is not as bad
as it might seem. From the programmer's point of view, I'd actually
prefer it - a final decision is made by the caller which increases
readability in another sense (pretty much like if (!func()) {...} does).
But that's my personal preference :)
br,
risto
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
