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

Yes, I agree, you've already creating enough entropy as to continue  
discussing it ;)
--
Alejandro Guerrieri
[email protected]



El 08/12/2008, a las 10:36 p.m., Nikos Balkanas escribió:

> 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]
>>>
>>>
>>
>