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]
