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 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.
agree'ing here to Aarno in FULL EXTEND. It's the "experience" of those 'guardians of the sacred treasury' that people tend to see only their (accurate) real world problem they want to solve. Mainly fast, and without to much effort. But this does not imply that it is the "best" solution. We *need* to think, in order to achieve abstraction for various SMSC protocolls.
I also agree that re-formulation of certain portions is legitim. But it's a complex aim, and there is nothing like "hmmm, ahhhh, ok, I thought about it, hmmm, ok, let's do it the ugly way" thing. Architecture design has to be clean, otherwise maintainership gets too fragmented and support level descrease, since developers tend to say "ahh, that's not my code, I wasn't agree'ing to add this to cvs, I won't review or fix it".
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 ?
don't know right now, but *yes* we need this mapping cleanly and garantee'ing per message uniqueness.
Stipe
mailto:stolj_{at}_wapme.de ------------------------------------------------------------------- Wapme Systems AG
Vogelsanger Weg 80 40470 D�sseldorf, NRW, Germany
phone: +49.211.74845.0 fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de http://www.wapme-systems.de/ -------------------------------------------------------------------
