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
