That sounds very interesting, and I'd like to see it happening as it will allow me to move functionality from the application to Kannel (which is the other way around then my team leader likes - and I'm fine with that ;-). I'm willing to tackle it, and I have some spare time coming.
-- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 +972-67-340014 ::.. The shortest distance between two points is under construction. > -----Original Message----- > From: Stipe Tolj [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 27, 2002 3:16 PM > To: Stefan Cars > Cc: Cipher Strength; [EMAIL PROTECTED] > Subject: Re: SMSC throughput > > > Stefan Cars wrote: > > > > I def. think that this should be recoded to be valid for > all SMSCs... > > Right now the only way for us to handle this trouble > (throughput problems > > 10 / sms sec for both our CIMD2 and SMPP) is to have an > application before > > kannel that don't feed kannel with more than that! > > yep, I'm usually very conservative for the functional scope of Kannel, > i.e. adding extra features that usually should be processes in the > backend systems. > > But in this case we should consider Kannel as a sink of all MO > messages and hence allow backend systems to use Kannel's sendsms > interface without timing very transparently. Hence recoding the > queueing feature should be done IMO, I'm +1 for this in the upcoming > development branch. > > Any votes and volonteers for this? > > Stipe > > [EMAIL PROTECTED] > ------------------------------------------------------------------- > Wapme Systems AG > > Vogelsanger Weg 80 > 40470 D�sseldorf > > Tel: +49-211-74845-0 > Fax: +49-211-74845-299 > > E-Mail: [EMAIL PROTECTED] > Internet: http://www.wapme-systems.de > ------------------------------------------------------------------- > wapme.net - wherever you are > >
