Re: Kannel is suffering [Really idea for dealing with SMPP TLV andEMI TTLLDD)]

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 implementation.
> 
> 
> And I am seeing them used more and more in real live situations,
> particularly for premium billing in networks. They are here to
> stay and becoming more popular.

agreed. There *is* definetly a demand in the user's space, which we have to address.

>> - Kannel development Standard Operation Procedure is to keep
>>   SMSC specific features and capabilities out of the abstract
>>   representation of an SMS as declared by the SMS Msg structure.
> 
> 
> This is a great *objective*.
> 
> Historical note - back in 2001 I provided an extensions mechanism for
> the Msg struct to the list. It was rejected at the time but I used it
> and continue to use it for the purposes described above.

ok, where is it? I can't recall it to have it reviewed. And obviously Alex would 
like to drop his eyes too on that things.

Paul, can you reference the mail that was provided to the list, or even better, 
resubmit?

> I've worked with protocols and encodings for a long long time. And each
> one has displayed symptoms as described above. Consider that HTTP and
> SMTP have X- headers for ad-hoc extensibility, X.509 has extensions etc.
> 
> IMHO, anything thats used in the real world needs a bit bucket to
> support
> the various business cases that evolve around it.

agreed. The discussion we had about optional parameters of specific protocols 
*has* brought us to the point, where we reflect that market demand has changed, 
and the "easy" position in saying "nop, it's not that good abstractable for all 
smsc types" can't be legitim in that sense anymore. We have to evolve to support 
market demands better.

So, an option is of course having a "dynamical" extendable Msg struct kind of 
thing. Can you resubmit it, please?

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