>3) This solution cannot be abstracted and used for all SMSC interfaces
> (unless all you want is the 'ts' field reported for every SMSC).
It appears to me, that progress of the Kannel project is severely hindered by
a group of people, which think that the lowest common denominator of all
featu
"Lowest common denominator" is *very* different thing than abstraction.
We either add all kind of random things to Kannel, making it very
difficult to use and maintain, or create a common abstraction with
different implementations for each instances a certain feature is
required.
Imagine what Kanne
Aarno Syvänen wrote:
"Lowest common denominator" is *very* different thing than abstraction.
We either add all kind of random things to Kannel, making it very
difficult to use and maintain, or create a common abstraction with
different implementations for each instances a certain feature is
require
Dear Aarno Syvänen and Stipe Tolj.
Thank you, I appreciate your comments. They are fully validating my
observations.
You are busy preserving the 'pure' design instead of thinking forward.
In that way Kannel will die.
You may distingush between 'lowest common denominator' and 'abstraction', but
Jørgen Thomsen wrote:
Dear Aarno Syvänen and Stipe Tolj.
Thank you, I appreciate your comments. They are fully validating my
observations.
You are busy preserving the 'pure' design instead of thinking forward.
In that way Kannel will die.
You may distingush between 'lowest common denominator' an
>
>now, first of all. This "policy", if I'm free to proclaim it in that way, is
>not
>invented by people maintaining Kannel.
Maybe not, but implemented by them according to their own preferences.
>I don't see any equation of 'lowest common denominator' and 'abstraction'. We
>never put this equ
Jørgen Thomsen wrote:
OK. Here is one practical issue, which deliberately has been turned down:
implementation of complete official protocol standards.
ok. This is the "utopia" we are looking to gain. But how to achieve it in a
practical abstraction and real world?
Now, I don't want to be picky.
Replying to Stipe Tolj:
> now, first of all. This "policy", if I'm free to proclaim it in that way,
> is not invented by people maintaining Kannel. It's "invented" by various
> other open source projects where not only software engeneering aspects come
> in play, but also politics, in some sence
Replying to Stipe Tolj:
And for the record. From my experience.
Politics and efficiency are orthogonal in best case. In worst case
politics is counterproductive.
Real life lies between that two, and, as you can see, there isn't any
gains in being err, umm, "political".
--
Paul P 'Stingray' Komko
> Frequently the efforts seen here are not to abstract, but to turn down
suggestions,
> because they are not present in all protocols. That is not abstraction.
That is backward
> thinking. Kannel would benefit from some real abstraction efforts with a
forward view of
> supporting all protocols
Paul P Komkoff Jr wrote:
Replying to Stipe Tolj:
now, first of all. This "policy", if I'm free to proclaim it in that way,
is not invented by people maintaining Kannel. It's "invented" by various
other open source projects where not only software engeneering aspects come
in play, but also politi
If we were to implement official protocol standards, we must make
difference between
genuine optional (used by one/some protocol) or things common with all
protocols, and
needed by users of all protocols. Last ones *must* be handled by
abstraction (we must
maintain all protocols, and without cod
Replying to Stipe Tolj:
> I agree. In that extend that "ugly pachtes" are getting in if the
> "demanding market" is really that big.
>
> Ok, some may say now: "you say a) and then b) again, which is contrairy".
> No! What I mean is that the group is not a group of puristic people (ok,
> let's d
>To quote Linus Torvalds: "As such, my most important function is to say NO!
>to people.
And rightfully so, but this nay-saying must be done on a sound theoretical
basis.
As for the CGI example, this is an entire subsystem, which traditionally does
not belong
in a kernel and can be implemented
Stipe Tolj,
>So, how about giving a concret example on how you would do certain issues?
Don't BS me. I have provided several patches to Kannel, and I did submit a
working patch
for a feature related to this issue, but about 2½ hour after my submission, you
flatly
turned it down. Not much time f
Jørgen Thomsen wrote:
And, please, don't drag the discussion here down to whether that small patch is
good or
not. More important issues are at stake. They go way beyond the rejection of a
single
patch ie. should Kannel be a 'lowest common denominator' software or should it
be a
framework to han
>> patch ie. should Kannel be a 'lowest common denominator' software or should
>> it be a
>> framework to handle several protocols as 'abstracted' as possible but with
>> provisions
>> for handling all aspects of a specific protocol.
>>
>> In my view the latter is a much more useful and challeng
**>From: Jørgen Thomsen <[EMAIL PROTECTED]>
**>To: devel
**>Subject: Re: Kannel is suffering
**>Date: Tue, 15 Feb 2005 23:48:11 +0100
**>In-Reply-To: <[EMAIL PROTECTED]>
[ ... lines deleted ... ]
**>Exactly.
**>One place to start could be better documentation
Davy Chan wrote:
Learn from the the mistakes of the 14th century missionaries. They
went out to contribute to the advancement of native people. But, ultimately
they destroyed the civilizaton of their "saved" people because they didn't
invest the time to understand their culture.
an intreresting (ev
On Sat, 12 Feb 2005, Jørgen Thomsen wrote:
should [Kannel] be a framework to handle several protocols as
'abstracted' as possible but with provisions for handling all aspects of
a specific protocol.
In my view the latter is a much more useful and challenging point of view.
+1. While I agree with
>
> - SMPP and EMI both have extra parameters or options that can
>be passed back and forth between the SMSC Servers and the
>SMSC clients.
> - The extra parameters are proprietary to the SMPP or EMI
>specifications and cannot be abstracted to be used by other
>SMSC client implem
Paul Keogh wrote:
- SMPP and EMI both have extra parameters or options that can
be passed back and forth between the SMSC Servers and the
SMSC clients.
- The extra parameters are proprietary to the SMPP or EMI
specifications and cannot be abstracted to be used by other
SMSC client implement
**>From: Jørgen Thomsen <[EMAIL PROTECTED]>
**>To: devel
**>Subject: Re: Kannel is suffering
**>Date: Sat, 12 Feb 2005 01:23:24 +0100
**>In-Reply-To: <[EMAIL PROTECTED]>
**>
**>Stipe Tolj,
**>
**>>So, how about giving a concret example on how you would
Davy Chan wrote:
Ok. Let's break down the current situation.
- SMPP and EMI both have extra parameters or options that can
be passed back and forth between the SMSC Servers and the
SMSC clients.
- The extra parameters are proprietary to the SMPP or EMI
specifications and cannot be abstra
24 matches
Mail list logo
