Also - as part of my feature request - I want the conditions evaluated
in order from first to last so that if any condition fails then it stops
evaluating further. There are several reasons for this.
First - it is faster. If a condition fails - move on.
But more importantly - suppose condition1 tests for the existence of a
file. Condition2 tests the contents of that file. If you do a straight
AND then if the file doesn't exist the second part of the conditional
can error out trying to open the file and it ends up stuck in DEFER land.
If the conditions are evaluated in order then if the file doesn't exist
it won't try to open the file.
Furthermore - and this is important - the code is far less confusing to
read and set up. Ease of use is important. The AND is ugly code.
Eli wrote:
>Wakko Warner wrote:
>
>
>>>I know you can do that and it's ugly. What I weant to additionally
>>>do is:
>>>
>>>condition = condition1
>>>condition = condition2
>>>
>>>
>
>I'll second the want for this exact feature. I know you can pile all your
>conditions into one statement, but depending how much you have to do, it
>could end up being a very long string (could the 1024 char limit cause
>problems here?). It also makes it a *real* pain when you want to have a
>bunch of different type of conditions like some MySQL lookups here, then
>some other stuff there, etc... I ran in to this exact issue when designing
>my Vacation router - I wanted to prevent replies going to null senders,
>etc... And also do a MySQL lookup. I had so many opening and closing {}
>brackets that it took me like 10 tests to get it all right! Not to mention
>as soon as I wanted to change something, I had to break it all apart again
>and then put it back together and test a bunch more times. I've never had
>that confusion with my other simpler condition statements because they avoid
>me using and/or conditions.
>
>
>
>>I thought about having 2 new conditions on the routers. Basically
>>they'd call the ACL code to do the conditioning. A precondition one
>>and a condition one. I just haven't bothered to see if it could
>>easily be done.
>>
>>
>
>As soon as you put a limit on the number of conditions you can do, people
>will always say they want more (acl variables for example). It would be
>nicer to just allow multiple condition statements just as you can in ACLs,
>and just have them processed in the order they're read in (since all will
>have to pass to have the router run, order shouldn't matter).
>
>
>
>>I would think this would satisfy multiple conditions and actually
>>remove options from routers that are already dupilcated in the ACLs.
>>
>>The acl would only support accept and deny. Obviously somethings
>>like delay and control wouldn't be useful.
>>
>>
>
>That could be an additional feature possibly - allow for an acl = statement
>just as in ACL's themselves - allowing a router to call an ACL as a
>condition... But would that provide any benefit over condition =, and would
>it invoke additional confusion about "is this or that variable available
>when running an ACL from a router"?
>
>I think for now just allowing multiple (unlimited) condition = statements in
>routers (and transports!) would be a great benefit, maybe not for the people
>writing the code, but for the people who like simplicity in their config
>files :)
>
>Eli.
>
>
>
>
