On Wednesday 25 May 2011, Daniel-Constantin Mierla wrote:
[..]
The comment "#!KAMILIO" was used to activate the compatibility mode. With 3.1 release this is not needed anymore.
Is this note written somewhere? If yes, then it should be removed, but otherwise I see no reason to bother with a comment line in order to add more comments.
Hello,
(moved to devel)
i did a quick check to the code, indeed all of the conditions where the mode was checked are gone now. If nobody object i'd also remove the support for this directive in the configuration parser, then its gone from the core completly.
Cheers,
Henning
On Wednesday 25 May 2011, Henning Westerholt wrote:
The comment "#!KAMILIO" was used to activate the compatibility mode. With 3.1 release this is not needed anymore.
Is this note written somewhere? If yes, then it should be removed, but otherwise I see no reason to bother with a comment line in order to add more comments.
i did a quick check to the code, indeed all of the conditions where the mode was checked are gone now. If nobody object i'd also remove the support for this directive in the configuration parser, then its gone from the core completly.
Well, its gone from the modules, but still included in the parser. Here there are two difference in variable parsing code between SER and Kamailio mode.
Cheers,
Henning
Am 25.05.2011 17:54, schrieb Henning Westerholt:
On Wednesday 25 May 2011, Henning Westerholt wrote:
The comment "#!KAMILIO" was used to activate the compatibility mode. With 3.1 release this is not needed anymore.
Is this note written somewhere? If yes, then it should be removed, but otherwise I see no reason to bother with a comment line in order to add more comments.
i did a quick check to the code, indeed all of the conditions where the mode was checked are gone now. If nobody object i'd also remove the support for this directive in the configuration parser, then its gone from the core completly.
Well, its gone from the modules, but still included in the parser. Here there are two difference in variable parsing code between SER and Kamailio mode.
What exactly is the difference?
It would be great if we could unify SER and Kamailio.
regards klaus
Klaus Darilion writes:
What exactly is the difference?
It would be great if we could unify SER and Kamailio.
that would indeed be great. one difference is in module interface. in k modules, arguments need to be in quotes, but not in s modules. this creates lots of confusion when using both s and k modules.
-- juha
On 5/25/11 6:35 PM, Juha Heinanen wrote:
Klaus Darilion writes:
What exactly is the difference?
It would be great if we could unify SER and Kamailio.
that would indeed be great.
hmm, that was probably left in Andrei's work, I removed everything I added to 3.0 in regard to compatibility mode in 3.1, I will check the sources.
one difference is in module interface. in k modules, arguments need to be in quotes, but not in s modules. this creates lots of confusion when using both s and k modules.
This shouldn't be valid. IIRC, it is a matter of the parser, not the module interface. What function from K modules you tried and what were the parameters?
Cheers, Daniel
Daniel-Constantin Mierla writes:
This shouldn't be valid. IIRC, it is a matter of the parser, not the module interface. What function from K modules you tried and what were the parameters?
for example, is_avp_set function requires that argument avp is given in quotes.
-- juha
On Wednesday 25 May 2011, Klaus Darilion wrote:
[..]
Well, its gone from the modules, but still included in the parser. Here there are two difference in variable parsing code between SER and Kamailio mode.
What exactly is the difference?
It would be great if we could unify SER and Kamailio.
Hey Klaus,
the difference is in the AVP/PV syntax e.g. in $ and $(..):
For the $(..), in ser mode it parses to an AVP, in all other modes it parses to a PV.
For the $, in ser mode it parses to an AVP, in kamailio mode it parses to a PV, in all other modes mode it parses to an AVP or PV, depending on the variable type.
What about this:
Remove all modes but the one for ser. Then people which use ser style scripts are still able to use them and don't need to change anything. All others can forget about the defines and we would also have only one default cfg style in this regards, which would be nice, IMHO.
Cheers,
Henning
On 26.05.2011 18:07, Henning Westerholt wrote:
On Wednesday 25 May 2011, Klaus Darilion wrote:
[..]
Well, its gone from the modules, but still included in the parser. Here there are two difference in variable parsing code between SER and Kamailio mode.
What exactly is the difference?
It would be great if we could unify SER and Kamailio.
Hey Klaus,
the difference is in the AVP/PV syntax e.g. in $ and $(..):
For the $(..), in ser mode it parses to an AVP, in all other modes it parses to a PV.
For the $, in ser mode it parses to an AVP, in kamailio mode it parses to a PV, in all other modes mode it parses to an AVP or PV, depending on the variable type.
What about this:
Remove all modes but the one for ser. Then people which use ser style scripts are still able to use them and don't need to change anything. All others can forget about the defines and we would also have only one default cfg style in this regards, which would be nice, IMHO.
There is one thing I still do not understand: How is ser or kamailio mode chosen? By #!KAMAILIO in kamailio.cfg or by FLAVOUR=kamailio?
Thanks klaus
On Thursday 26 May 2011, Klaus Darilion wrote:
[..]
Remove all modes but the one for ser. Then people which use ser style scripts are still able to use them and don't need to change anything. All others can forget about the defines and we would also have only one default cfg style in this regards, which would be nice, IMHO.
There is one thing I still do not understand: How is ser or kamailio mode chosen? By #!KAMAILIO in kamailio.cfg or by FLAVOUR=kamailio?
Hi Klaus,
with regards to the configuration syntax style its just specificed by the #!KAMAILIO or #!SER macro in the cfg.
Cheers,
Henning