Allow cfg_get parameters to be used as modparams, too, so I can define one set of global database properties and pass them as db_urls to every module that uses one and also to 'sqlops' as an 'sqlcon', and similar things.
Alex Balashov wrote:
Allow cfg_get parameters to be used as modparams, too, so I can define one set of global database properties and pass them as db_urls to every module that uses one and also to 'sqlops' as an 'sqlcon', and similar things.
Hello Alex,
I don't know if this is exactly your wish but if you specify cfg_get parameters as module parameters than you get the desired effect.
For example in carrierroute module (master branch), in the definition of modules parameters I have ... {"use_domain", INT_PARAM, &default_carrierroute_cfg.use_domain } ...
You can set/get use_domain via the cfg framework at runtime(using sercmd), or initially via modparam...
This is what you wanted ?
Marius
Almost, except I need to be able to define this independently for custom purposes. For example:
modparam("permissions", "db_url", "postgres:// @cfg_get.db.user:@cfg_get.db.password@@cfg_get.db.host/ @cfg_get.user.dbname")
-- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892
On Apr 9, 2010, at 4:44 AM, marius zbihlei marius.zbihlei@1and1.ro wrote:
Alex Balashov wrote:
Allow cfg_get parameters to be used as modparams, too, so I can define one set of global database properties and pass them as db_urls to every module that uses one and also to 'sqlops' as an 'sqlcon', and similar things.
Hello Alex,
I don't know if this is exactly your wish but if you specify cfg_get parameters as module parameters than you get the desired effect.
For example in carrierroute module (master branch), in the definition of modules parameters I have ... {"use_domain", INT_PARAM, &default_carrierroute_cfg.use_domain } ...
You can set/get use_domain via the cfg framework at runtime(using sercmd), or initially via modparam...
This is what you wanted ?
Marius
Alex Balashov wrote:
Almost, except I need to be able to define this independently for custom purposes. For example:
modparam("permissions", "db_url", "postgres://@cfg_get.db.user:@cfg_get.db.password@@cfg_get.db.host/@cfg_get.user.dbname")
--
Hello Alex,
I see what you mean, but I don't really know if it's possible, because at the time of module initialization some core cfg's might not be registered(especially for built-in modules which are initialized before sr_cfg_init() ).
Marius
Marius,
On 04/09/2010 08:50 AM, marius zbihlei wrote:
I see what you mean, but I don't really know if it's possible, because at the time of module initialization some core cfg's might not be registered(especially for built-in modules which are initialized before sr_cfg_init() ).
I understand the practical obstacles, and that it may not be possible.
The reason I would like this is that I have a flexible configuration I reuse that has different modules loaded, primarily based on preprocessor macros (#!ifdef ... #!endif). Thus, it is not possible in advance to know which modules will be loaded, nor possible to iterate through some list and combine them into a string, so I cannot do:
modparam("mod1|mod2|mod3", "db_url", ...)
As a result, I have to have a manual db_url setting for every module as well as at least one DB URL as an 'sqlcon' parameter to 'sqlops'.
It is very frustrating and tedious to have to deal with problems like this. I have written a Perl script to recursively update all db_url's automatically, but it is an inelegant stopgap solution. There are also other situations in which the ability to include some sort of PV or variable (that is statically initialised globally) in the modparams.
Hello Alex,
Thus, it is not possible in advance to know which modules will be loaded, nor possible to iterate through some list and combine them into a string, so I cannot do:
modparam("mod1|mod2|mod3", "db_url", ...)
Regarding the modparam statement, I think you can. Unfortunately, I can't test it a.t.m., but as far as I remember I think the modparam statement succeeds even if only one of the modules listed in the module section is configured correctly. For example you can have something like
modparam("carrierroute|xyz", "db_url", ....)
and work, even if xyz module doesn't exist (yet).
As another approach goes, I was thinking of having something like a preprocessor for ser cfg language. The lexer now only supports #define and #ifdef's but doesn't support macro substitution. The #define's and #ifdef's are integrated into the lexer and not an performed as a separate initial step, thus full macro support is hard to integrate.
Your code might look smth like this :
#define DBURL "mysql://..."
modparam("module", "db_url", DBURL)
In my opinion it will be a nice feature.
Marius
-----Original Message----- From: Alex Balashov [mailto:abalashov@evaristesys.com] Sent: Fri 4/9/2010 2:53 PM To: Marius Zbihlei Cc: SR-Users Subject: Re: [SR-Users] My wish
Marius,
On 04/09/2010 08:50 AM, marius zbihlei wrote:
I see what you mean, but I don't really know if it's possible, because at the time of module initialization some core cfg's might not be registered(especially for built-in modules which are initialized before sr_cfg_init() ).
I understand the practical obstacles, and that it may not be possible.
The reason I would like this is that I have a flexible configuration I reuse that has different modules loaded, primarily based on preprocessor macros (#!ifdef ... #!endif). Thus, it is not possible in advance to know which modules will be loaded, nor possible to iterate through some list and combine them into a string, so I cannot do:
modparam("mod1|mod2|mod3", "db_url", ...)
As a result, I have to have a manual db_url setting for every module as well as at least one DB URL as an 'sqlcon' parameter to 'sqlops'.
It is very frustrating and tedious to have to deal with problems like this. I have written a Perl script to recursively update all db_url's automatically, but it is an inelegant stopgap solution. There are also other situations in which the ability to include some sort of PV or variable (that is statically initialised globally) in the modparams.
Hi Marius,
On 04/10/2010 02:19 AM, Marius Zbihlei wrote:
Hello Alex,
Thus, it is not possible in advance to know which modules will be loaded, nor possible to iterate through some list and combine them into a string, so I cannot do:
modparam("mod1|mod2|mod3", "db_url", ...)
Regarding the modparam statement, I think you can. Unfortunately, I can't test it a.t.m., but as far as I remember I think the modparam statement succeeds even if only one of the modules listed in the module section is configured correctly. For example you can have something like
modparam("carrierroute|xyz", "db_url", ....)
and work, even if xyz module doesn't exist (yet).
I agree, this is possible, but I find it an inelegant solution; it still requires me to anticipate every conceivable module that could be loaded elsewhere in the configuration, and this is not as easy as it sounds given its highly flexible, indeterminate nature. It's also just not pretty.
As another approach goes, I was thinking of having something like a preprocessor for ser cfg language. The lexer now only supports #define and #ifdef's but doesn't support macro substitution. The #define's and #ifdef's are integrated into the lexer and not an performed as a separate initial step, thus full macro support is hard to integrate.
Your code might look smth like this :
#define DBURL "mysql://..."
modparam("module", "db_url", DBURL)
In my opinion it will be a nice feature.
I agree, and think that would be wonderful. My only goal is to be able to define arbitrary constants in the config and use them anywhere in script, including module parameters.
Cheers,
Alex Balashov writes:
Your code might look smth like this :
#define DBURL "mysql://..."
modparam("module", "db_url", DBURL)
In my opinion it will be a nice feature.
I agree, and think that would be wonderful. My only goal is to be able to define arbitrary constants in the config and use them anywhere in script, including module parameters.
since M4 has been already invented perhaps it would be better to use that for the above rather than use scarce developer resources to reinvent the wheel.
-- juha
On 04/10/2010 02:31 AM, Juha Heinanen wrote:
since M4 has been already invented perhaps it would be better to use that for the above rather than use scarce developer resources to reinvent the wheel.
In principle, I agree.
However, this very same argument could be made against features like 'include_file' and #!ifdef & friends, and some other things that have made Kamailio 3.x much better than 1.x from a code management perspective. These features have revolutionised our deployment, standardisation and maintenance process.
It is true that with enough spiritual commitment, we could have achieved them before by using m4. It would have allowed us to split elements of configuration across many files, perform global substitutions, etc. And yet, it was just too hard to get the initiative to learn it and do it, especially since it appeared that this approach would have been obsoleted by new Kamailio 3.x features anyway.
My point is that those features served to simplify and somewhat democratise the process of better code organisation, dynamism and maintenance, even though there were other ways to achieve the same objectives.
Alex Balashov writes:
However, this very same argument could be made against features like 'include_file' and #!ifdef & friends, and some other things that have made Kamailio 3.x much better than 1.x from a code management perspective. These features have revolutionised our deployment, standardisation and maintenance process.
i agree and since i'm using M4 is have had no use of #!ifdef & friends, because (as you point out) those alone are not powerful enough. so either embed all M4 features in sr or none and use M4 instead.
i vote for using core developer resources to add real new value rather that re-implement M4 in sr.
-- juha
On 04/10/2010 03:04 AM, Juha Heinanen wrote:
Alex Balashov writes:
However, this very same argument could be made against features like 'include_file' and #!ifdef& friends, and some other things that have made Kamailio 3.x much better than 1.x from a code management perspective. These features have revolutionised our deployment, standardisation and maintenance process.
i agree and since i'm using M4 is have had no use of #!ifdef& friends, because (as you point out) those alone are not powerful enough. so either embed all M4 features in sr or none and use M4 instead.
I think there may be an attractive middle ground here: support a preprocessor feature set natively that is roughly equivalent to the one provided by many other packages whose configuration files are semi-programmatic in nature, but leave the really advanced metaprogramming for those that need it to m4.
Alex Balashov wrote:
Hi Marius,
On 04/10/2010 02:19 AM, Marius Zbihlei wrote:
Hello Alex,
Thus, it is not possible in advance to know which modules will be loaded, nor possible to iterate through some list and combine them into a string, so I
cannot do:
modparam("mod1|mod2|mod3", "db_url", ...)
Regarding the modparam statement, I think you can. Unfortunately, I can't test it a.t.m., but as far as I remember I think the modparam statement succeeds even if only one of the modules listed in the module section is configured correctly. For example you can have something like
modparam("carrierroute|xyz", "db_url", ....)
and work, even if xyz module doesn't exist (yet).
I agree, this is possible, but I find it an inelegant solution; it still requires me to anticipate every conceivable module that could be loaded elsewhere in the configuration, and this is not as easy as it sounds given its highly flexible, indeterminate nature. It's also just not pretty.
Hello Alex,
How about a syntax like
modparam("*", "db_url", ...) ?
meaning that it matches all modules that have a db_url param. Maybe this will also benefit something like module specific log level(when will be implemented) and other common parameters.
Cheers Marius
On 04/12/2010 03:50 AM, marius zbihlei wrote:
Alex Balashov wrote:
Hi Marius,
On 04/10/2010 02:19 AM, Marius Zbihlei wrote:
Hello Alex,
Thus, it is not possible in advance to know which modules will be loaded, nor possible to iterate through some list and combine them into a string, so I
cannot do:
modparam("mod1|mod2|mod3", "db_url", ...)
Regarding the modparam statement, I think you can. Unfortunately, I can't test it a.t.m., but as far as I remember I think the modparam statement succeeds even if only one of the modules listed in the module section is configured correctly. For example you can have something like
modparam("carrierroute|xyz", "db_url", ....)
and work, even if xyz module doesn't exist (yet).
I agree, this is possible, but I find it an inelegant solution; it still requires me to anticipate every conceivable module that could be loaded elsewhere in the configuration, and this is not as easy as it sounds given its highly flexible, indeterminate nature. It's also just not pretty.
Hello Alex,
How about a syntax like
modparam("*", "db_url", ...) ?
meaning that it matches all modules that have a db_url param. Maybe this will also benefit something like module specific log level(when will be implemented) and other common parameters.
That would certainly solve the problem!
Hello Alex,
How about a syntax like
modparam("*", "db_url", ...) ?
meaning that it matches all modules that have a db_url param. Maybe this will also benefit something like module specific log level(when will be implemented) and other common parameters.
That would certainly solve the problem!
It seems that this is already implemented. Modparam function allows for a regexp match on the module name. Unfortunately, I can't text it right now, but browsing thru the code it seems that it supports the same regexp expression like the rest of Ser. Maybe something like this will work
modparam(".*", "db_url", ...);
Marius
marius zbihlei wrote:
Hello Alex,
How about a syntax like
modparam("*", "db_url", ...) ?
meaning that it matches all modules that have a db_url param. Maybe this will also benefit something like module specific log level(when will be implemented) and other common parameters.
That would certainly solve the problem!
It seems that this is already implemented. Modparam function allows for a regexp match on the module name. Unfortunately, I can't text it right now, but browsing thru the code it seems that it supports the same regexp expression like the rest of Ser. Maybe something like this will work
modparam(".*", "db_url", ...);
Marius
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello Alex
I had the time to test the previous mail and it doesn't work. The reason is that the if a regex match succeeds , than the parameter configured MUST exists in the module. I have created a patch that modifies this behavior and now the modparam statement succeeds if there is at least on module that can be configured with the desired param.
I have attached the patch. And now the question : does it make sense to push it to master?! In my opinion the relaxed approach is better that the greedy approach...
Marius
Marius,
Well, if you ask me whether it is worth pushing to master, you will get a rather biased answer. This sounds like a call that should be made by the elders of the Kamailio tribal council. :)
Thank you anyway for the patch; I will put it to good use!
-- Alex
-- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892
On Apr 12, 2010, at 6:15 AM, marius zbihlei marius.zbihlei@1and1.ro wrote:
marius zbihlei wrote:
Hello Alex,
How about a syntax like
modparam("*", "db_url", ...) ?
meaning that it matches all modules that have a db_url param. Maybe this will also benefit something like module specific log level(when will be implemented) and other common parameters.
That would certainly solve the problem!
It seems that this is already implemented. Modparam function allows for a regexp match on the module name. Unfortunately, I can't text it right now, but browsing thru the code it seems that it supports the same regexp expression like the rest of Ser. Maybe something like this will work
modparam(".*", "db_url", ...);
Marius
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello Alex
I had the time to test the previous mail and it doesn't work. The reason is that the if a regex match succeeds , than the parameter configured MUST exists in the module. I have created a patch that modifies this behavior and now the modparam statement succeeds if there is at least on module that can be configured with the desired param.
I have attached the patch. And now the question : does it make sense to push it to master?! In my opinion the relaxed approach is better that the greedy approach...
Marius
diff --git a/modparam.c b/modparam.c index ca34bef..115079a 100644 --- a/modparam.c +++ b/modparam.c @@ -57,7 +57,7 @@ int set_mod_param_regex(char* regex, char* name, modparam_t type, void* val) { struct sr_module* t; regex_t preg; - int mod_found, len; + int mod_found, len, var_found; char* reg; void *ptr, *val2; modparam_t param_type; @@ -90,6 +90,7 @@ int set_mod_param_regex (char* regex, char* name, modparam_t type, void* val) } mod_found = 0; + var_found = 0; for(t = modules; t; t = t->next) { if (regexec (&preg, t->exports->c.name, 0, 0, 0) == 0) { DBG ("set_mod_param_regex: '%s' matches module '%s'\n", @@ -99,6 +100,7 @@ int set_mod_param_regex(char* regex, char* name, modparam_t type, void* val) ptr = find_param_export(t, name, type | ((type & (PARAM_STR|PARAM_STRING))?PARAM_STR|PARAM_STRING:0), ¶m_type); if (ptr) { /* type casting */ + var_found = 1; if (type == PARAM_STRING && PARAM_TYPE_MASK(param_type) == PARAM_STR) { s.s = (char*)val; s.len = s.s ? strlen(s.s) : 0; @@ -146,11 +148,8 @@ int set_mod_param_regex(char* regex, char* name, modparam_t type, void* val) } } else { - LOG(L_ERR, "set_mod_param_regex: parameter <%s> not found in" + LOG(L_DBG, "set_mod_param_regex: parameter <%s> not found in" " module <%s>\n", name, t->exports->c.name); - regfree (&preg); - pkg_free(reg); - return -3; } } } @@ -161,5 +160,9 @@ int set_mod_param_regex(char* regex, char* name, modparam_t type, void* val) LOG(L_ERR, "set_mod_param_regex: No module matching <%s> found\n", regex); return -4; } + if(!var_found) { + LOG(L_ERR, "set_mod_param_regex: No module export matching <%s> found\n", name); + return -3; + } return 0; }
marius zbihlei writes:
I have attached the patch. And now the question : does it make sense to push it to master?! In my opinion the relaxed approach is better that the greedy approach...
i have had cases where name of a module parameter has been changed or the param has been replaced by something else that has required changed in the config. i have noticed that because of the error message, which has been useful.
-- juha
-
Alex Balashov -
jh＠tutpro.com -
marius zbihlei