Hello,

On 01/31/07 18:14, Bastian Friedrich wrote:
[...]
If you want to call xlog() from another module, you have to give the
list of elements as parameter, not the initial string.

Unfortunately, this is only possible if the types of parameters are known in advance; the way the moduleFunc function in the perl module is implemented, this is impossible, as it is meant to be an all-embracing solution for every type of function, with every type of fixup.
If you have the final text to be printed in Perl, it is no need to use xlog module, but you can use the log() function from core which gets a string as imput.
[...]

Unfortunately, this seems to be the only sensible solution for now. Another one might be an internal cache of references to fixed parameters for each triple of (function, parameter1, parameter2) - but that cache is not a quick hack, either, and it remains open whether it will be sufficient, as it might grow too big.

Tell me if you want me to disable the (implicit as well as explicit) module function calling.
I would rather make a list with functions compatible to be used from Perl, making a disable/enable mechanism at global lever for exported functions will cause the problems. People would not know which function will make the proxy crash or causes mem leaks.
I see no much benefit as long as they can be executed directly in configuration file. Access and management (rewrite uri, dst uri,
...)  sip_msg structure plus ability to set/get AVPs would be most of
what one would like to do in PERL applications.

I was contacted by a developer (not from the smallest company... :) who wants to use the body_replace function inside a perl script. The string to be replaced is dynamic in his context. All other functions inside the textops module are interesting, to say the least, and maybe even crucial in a lot of contexts.
The solution is here to make an API that will be exported bu the textops module and Perl will use that. It is what we did with sl module to avoid complications when using from other modules. Just tell me some priorities of the functions you want to have.

Regarding the avpops, there are functions in core that can be used to add/delete AVPs. Using avpops brings operations in script, operations that are easier to do directly in Perl (like regexp, comparisons, ....). acc and gflags are not that big deal to make an API out of exported functions.

Cheers,
Daniel

Although I implemented a xl_sprintf to read pseudo variables (which is currently flawed, too - patch will be on it's way shortly), the intended way to write them would have been through the avpops module; this one uses fixup functions, too...

Definitely interesting functions to be called from perl could be in:
* avpops
* textops
* acc
* gflags

Regards,
   Bastian


_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel

Reply via email to