On Fri, 9 Aug 2002, Stipe Tolj wrote: > > Well my question was not about how it can be done but how they do do it > > right now :] > > we do terminate and restart smsbox to re-read the updated > configuration.
Okay, just curious about possible open HTTP connections etc. so they do not cause problems? (like lost replies later on requeed with store system) > > What I meant here is that dynamic configuration loading inside Kannel > > without stopping the smsc connections can be done (quite easily), thus > > effectually same thing as never stopping bearerbox but restarting smsbox > > which is what we do. > > But you still have to stop and restart bearerbox if you change smsc > groups (adding or modifying) and hence those who are not affected have > to go down and up too. Yes, the same way it goes with the integrated one. > I'm also thinking of problems arrising from the planed modularization. > As far as I see we will have modularization (which is already there) > for SMSC modules and SMS services (i.e. sendsms, sendota, > sendringtone, sendlogo etc). which means if someone links in a SMS > service module (into smsbox scope) and smsbox is implemented as > threads inside bearerbox and the new code dumps core, the whole > systems blows up. Which is not the way we would like to see it. That is a valid point. If I start to speak ideally, I would get rid of all such services and instead implement just one simple http sender/receiver and all those services would be done by external filter/proxy/whatever. No idea to make basic _gateway_ an application server. But that is of course 'if I was the king of the world and would do redo everything' -talk. Things that aleady exist are hard to move away (like those prefix-suffix things in sms-service groups.. one in 200 uses them and thus they cannot be removed and left to be application problem..) -- &kalle marjola product concept manager NETikos finland (http://www.netikos.fi)
