"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 Kannel would look like, if all SMSCs were coded totally separately, without any common features ? So people are *not* against new features, we must just do some thinking before adding them.
Message identification is already used by all SMSCs, question is how to abstract this notion properly. In some SMSCs message identification is "timestamp+other fields", in SMPP it is true message id. Perhaps one should configure this at smsc group level ?
Aarno
On 10.2.2005, at 10:59, J�rgen Thomsen wrote:
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
features are the only things, that can be implemented.
If Kannel is not going to deteriorate into an academic exercise of 'pure'
design, we need a changed view of this. There are real world needs, which must
be covered.
It is not acceptable, that because a feature is not available in all
protocols, it should not be available in any.
The core of Kannel must of course be a generic engine, but there must be a
framework, so that protocol-specific features can be added to this engine with
minimal impact to others.
I think the 'guardians of the sacred treasury' should do some rethinking and
find out how this framework can be implemented. This would benefit Kannel
tremendously.
- J�rgen Thomsen
