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