AFAIK this was not implemented so far.
Regarding performance, if the options are converted into regular
configuration parameters (Kannel has very well defined configuration
structures that wouldn't change at all I think) the impact would be
negligible (probably just a few milliseconds during startup).
Regards,
--
Alejandro Guerrieri
[EMAIL PROTECTED]
El 08/12/2008, a las 07:40 a.m., Nikos Balkanas escribió:
Still now has only 1 option to check (in memory). If you triple the
options then you will have 3 times as many checks x number they
appear in code. In general "option explosion" is to be avoided,
unless necessary. Makes for more complex configuration and degraded
performance.
----- Original Message ----- From: "Ehizogie Binitie" <[EMAIL PROTECTED]
>
To: "Nikos Balkanas" <[EMAIL PROTECTED]>
Cc: "devel" <[email protected]>
Sent: Monday, December 08, 2008 10:47 AM
Subject: Re: Re:[REQ] generic config struct for parameter value lists
I don't imagine performance will be significan'tly affected since
these
parameters are initialized on startup and loaded into memory.
Ehi
On Sun, 2008-12-07 at 23:32 +0200, Nikos Balkanas wrote:
When was it proposed? How is it going to affect performance?
BR,
Nikos
----- Original Message ----- From: "Ehizogie Binitie" <[EMAIL PROTECTED]
>
To: "devel" <[email protected]>
Sent: Sunday, December 07, 2008 9:07 PM
Subject: Re:[REQ] generic config struct for parameter value lists
Hi List,
Was this feature proposed by Stipe ever implemented ?
I think its an excellent idea.
Ehi
------------------------------------------------------------------------------------------
Hi list,
I have some good input on extending Kannel's config handling
abilities:
Currently we have several needs for a config value list, some
examples:
group = smsc
...
accepted-smsc-id = "A;B;C"
group = sms-service
...
aliases = "key2;key3;key4"
group = smsbox-route
...
shortcode = "1111;2222;3333"
so, all of these are either of type word-list or id-list,
semantically
it's a
semicolon seperated list. For some parts we have defined foobar-
regex
config
directives to handle PCRE/regex for a more simple definition.
The idea now is to create a more generic construct for this, which
handles 3
(maybe more?) different ways for any "list-type":
foobar = "A;B;C"
foobar-url = "http://somewhere/foobar-list";
foobar-regex = "<the regex expression>"
so users can *CHOOSE* which way they prefer. And we handle the
processing of the
list "transparently" to the logic that requires the list from the
config
sections.
I like this concept of abstraction here. Since we would
encapsulate the
plain,
-url and -regex handling to the scope of gwlib/cfg.{ch] and the
other
calling
modules simply pull for the list.
Thoughts?
-------------------------------------------------------------------
Kölner Landstrasse 419
40589 DΓΌsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
--
Ehizogie Binitie
Director, Product Management and Marketing
Rancard Solutions Ltd
TOP SOFTWARE COMPANY OF THE YEAR (Ghana)
Web: www.rancardmobility.com
mobile: +233 244 980 569
office: +233 28 952 9573
email: [EMAIL PROTECTED]
