Hi Henning,
We need to consider the user (script writer) experience also. As Klaus
stated, there are many function just breaking script (returning script)
because the user should not do anything further.
The best example is t_newtran() or t_check_trans() - if a retransmission
is detected, TM
On 03/03/08 06:21, Juha Heinanen wrote:
i noticed that if allow_source_address_from_group() returns group value
0, statement
$var(group) = allow_source_address_from_group();
never returns. is this intentional, i.e., are functions disallowed to
return value 0?
by returning 0, the
Daniel-Constantin Mierla writes:
by returning 0, the execution of the script is interrupted -- same
behavior as 'exit'.
that is what i suspected. in my opinion there is too much under cover
things happening here. it would be easier to debug and understand
things if script would not
Daniel-Constantin Mierla writes:
perhaps going to clear return codes handling will be better. Since the
beginning of ser, the meaning of return codes was:
- greater than 0 was considered true
- less than 0 was considered false
- 0 was considered exit.
Now it is about backward
El Monday 03 March 2008 09:54:23 Juha Heinanen escribió:
Daniel-Constantin Mierla writes:
perhaps going to clear return codes handling will be better. Since the
beginning of ser, the meaning of return codes was:
- greater than 0 was considered true
- less than 0 was considered false
On Monday 03 March 2008, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
perhaps going to clear return codes handling will be better. Since
the beginning of ser, the meaning of return codes was:
- greater than 0 was considered true
- less than 0 was considered false
- 0 was
Dan Pascu writes:
My guess is that this will not be easy to do as there are currently
functions that rely on this to stop processing the message and they do so
based on some internal checks/conditions that are not testable from the
script.
are you saying that you have lots of
On Monday 03 March 2008, Juha Heinanen wrote:
Dan Pascu writes:
My guess is that this will not be easy to do as there are currently
functions that rely on this to stop processing the message and they
do so based on some internal checks/conditions that are not testable
from the script.
Dan Pascu writes:
AFAIK, there are functions in tm that rely on this, including t_relay if
I'm not mistaken. I'd say that until a list of the module functions that
use this behavior is made so we can draw a conclusion, it's premature to
assume this will be easy to change, or that is
On Monday 03 March 2008, Juha Heinanen wrote:
Dan Pascu writes:
AFAIK, there are functions in tm that rely on this, including t_relay if
I'm not mistaken. I'd say that until a list of the module functions that
use this behavior is made so we can draw a conclusion, it's premature to
Henning Westerholt writes:
yes, i've also the same opinion. But there will be probably many
configs out there that do rely on this behaviour, and will break if
we change this. So i also think this is not something that we should
treat lightly.
in that case perhaps we can add a config
On Monday 03 March 2008, Juha Heinanen wrote:
Dan Pascu writes:
AFAIK, there are functions in tm that rely on this, including
t_relay if I'm not mistaken. I'd say that until a list of the module
functions that use this behavior is made so we can draw a
conclusion, it's premature to
Juha Heinanen wrote:
Dan Pascu writes:
My guess is that this will not be easy to do as there are currently
functions that rely on this to stop processing the message and they do so
based on some internal checks/conditions that are not testable from the
script.
are you saying
i noticed that if allow_source_address_from_group() returns group value
0, statement
$var(group) = allow_source_address_from_group();
never returns. is this intentional, i.e., are functions disallowed to
return value 0?
-- juha
___
Devel mailing
14 matches
Mail list logo
