Re: [REQ] generic config struct for parameter value lists

I am sure that if you think it through you will come to the right 
conclusion. What you describe would violate the 2nd law of thermodynamics as 
applied to information:

"You cannot get something from nothing" or "you cannot get logic out of data 
(structures)"

But I am sure it is a minor issue, propably not worth allocating more space 
in the thread.

BR,
Nikos
----- Original Message ----- 
From: "Alejandro Guerrieri" <[email protected]>
To: "Nikos Balkanas" <[email protected]>
Cc: <[email protected]>; "devel" <[email protected]>
Sent: Monday, December 08, 2008 3:28 PM
Subject: Re: [REQ] generic config struct for parameter value lists


Nikos,

This wouldn't affect runtime at all. This only would add flexibility
on how to "explain" things to Kannel. The data would be parsed to
existing structures, at Kannel level there wouldn't be any difference
nor performance impact.

Regards,
--
Alejandro Guerrieri
[email protected]



El 08/12/2008, a las 11:09 a.m., Nikos Balkanas escribiΓ³:

> I was not exactly referring to startup code, but to runtime code and  how 
> many times these options appear. If you triple that time and  multiply by 
> how many times X how many points X messages/day these  options might be 
> invoked it could add up even if it is just an "if"  statement. Add to that 
> maintenance cost, larger code, more  maintenance. I prefer to be spartan 
> about it.
>
> BR,
> Nikos
> ----- Original Message ----- From: "Alejandro Guerrieri" 
> <[email protected]
> >
> To: "Nikos Balkanas" <[email protected]>
> Cc: <[email protected]>; "devel" <[email protected]>
> Sent: Monday, December 08, 2008 1:17 PM
> Subject: Re: [REQ] generic config struct for parameter value lists
>
>
> 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]
>>
>>
>