Re: Re:[REQ] generic config struct for parameter value lists
"Nikos Balkanas" <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <000301c95919$0ce7c4a0$02b2a8c0@tardis> |
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] >