On Wed, 5 Nov 2008, Risto Vaarandi wrote:
> John P. Rouillard wrote:
>> In message <[EMAIL PROTECTED]>,
>> Risto Vaarandi writes:
>>
>>> John P. Rouillard wrote:
>>>> In message <[EMAIL PROTECTED]>,
>>>> Risto Vaarandi writes:
>> 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 :)
I think it's much cleaner and more powerful to allow the branched set of
rules to do anything that the main rules can do. This includes setting
contexts that can be checked after a return (which would behave the way
you want), but it also includes the branched rules doing anything else,
including creating logs, taking actions, or delaring the line should be
ignored by all following rules.
using this sort of logic in iptables/ipchains I was able to take a 2000
line ruleset and reduce it down to 200 lines, with the result being much
easier to understand.
This sort of capability is _very_ powerful.
David Lang
-------------------------------------------------------------------------
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
