Re: Future of Kannel

> I don't see why .dso support for SMSC is of any help There are not  
> really any benefit to dynamically exchange SMSC modules as kannel  
> is the only user of this .dso

I suspect the point is more to only load code that is going to be  
used, so its more efficient. Although granted the code for each smsc  
implementation is not huge, and there are not thousands of different  
ones right now. I guess another advantage is easier development for  
people to write a new smsc implementation. They don't need to compile  
all of kannel, just  the smsc code.

>>>> e) MMSC??? ... which some of us have already.
>
> MMSC is not really the same as the goal of Kannel even though  
> Kannel can be a helper there. Furthermore there are not many  
> demands for MMSC's as most operators block access to their MMSC  
> network so a non operator can not make use of it.

An mmsc interface would be a nice feature, so mms message could be  
sent and received in the same was as sms.

>>> Now that Java is GPLv2, it might be an interesting challenge to  
>>> port at
>>> least some functionality of Kannel to Java (or some other modern
>>> language, for the sake of discussion) and see how it goes.
>
> Sure. you can restart from scratch and do your own kannel with less  
> performance and more bugs.

Thank goodness you said that, it certainly needed saying!


> TLV is something which is SPECIFIC to one SMSC driver (SMPP) and is  
> not supported in any other.
> Furthermore TLV's are used usually for operator specific quirks.  
> Not something standard. And for that its perfectly ok to maintain  
> your private patch to add this private feature as you will most  
> probably the only one needing it.

How about a more generic additional information structure for  
messages, then its up to the smsc code about how they are  
implemented, but it keeps it generic at the top level. Some form of  
key value pairs that can be included with the message would seem to  
be the way forward I suspect.

Ben
>