9 Apr
2010
9 Apr
'10
3:36 a.m.
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 - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
9 Apr
9 Apr
11:44 a.m.
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
12:15 p.m.
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(a)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
3:50 p.m.
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
3:53 p.m.
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.
--
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
Web: http://www.evaristesys.com/
10 Apr
10 Apr
9:19 a.m.
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.
--
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
Web: http://www.evaristesys.com/
9:26 a.m.
Hi Marius,
On 04/10/2010 02:19 AM, Marius Zbihlei wrote:
Hello Alex,
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.
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.
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 - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
9:31 a.m.
Alex Balashov writes:
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
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.
9:55 a.m.
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 - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
10:04 a.m.
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
10:17 a.m.
On 04/10/2010 03:04 AM, Juha Heinanen wrote:
Alex Balashov writes:
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 - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
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.
12 Apr
12 Apr
10:50 a.m.
Alex Balashov wrote:
Hi Marius,
On 04/10/2010 02:19 AM, 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.
Cheers
Marius
Hello Alex,
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. 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).
10:51 a.m.
On 04/12/2010 03:50 AM, marius zbihlei wrote:
Alex Balashov wrote:
That would certainly solve the problem!
--
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
Web: http://www.evaristesys.com/
Hi Marius,
On 04/10/2010 02:19 AM, 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. Hello Alex,
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. 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).
11:01 a.m.
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!
1:15 p.m.
marius zbihlei wrote:
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(a)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
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!
1:18 p.m.
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(a)1and1.ro>
wrote:
marius zbihlei wrote:
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(a)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; }
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!
1:23 p.m.
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
5338
days inactive
5341
days old
16 comments
3 participants
participants (3)
-
Alex Balashov -
jh＠tutpro.com -
marius zbihlei