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]
