Hi, I agree with Alejandro on this.
Am 18.12.2010 um 15:02 schrieb Alejandro Guerrieri: > An approach similar to the one we use with the smsc-admin-id would work > perfectly. > > smsbox-id, for routing. > smsbox-admin-id for sending commands. > >> A distributed management is always better than a centralized one as >> complexity scales up, and doesn't limit you to anything in simpler scenarios. > > I disagree with that, as most of the industry does. Clusters are managed from > a central place, not from each box alone (and I have my share of experience > with clusters to back my point). Might work for 2-3 boxes, but try to manage > 10 instances by hitting 10 different urls on 10 different servers. Scale that > to 100, 1000, 10000... > > Regards, > -- > Alejandro Guerrieri > aguerri...@kannel.org > > > > On 18/12/2010, at 14:48, Nikos Balkanas wrote: > >> I don't think that wholistic centralized management is an acceptable option. >> Even with centralized management smsbox-id will be required. There are >> several features that are only applicable to the particular instance you >> need them. For example, live reconfiguration of services or sendsms accounts >> to a particular smsbox. It is not available yet, but there is no benefit in >> excluding it from a future version. As far as the other smsbox types go >> (sqlbox, smppbox), they should be allowed to have their own sets of live >> parameters, completely different than standard smsbox, according to their >> needs without trapping them to an "smsbox format". These "extra features" or >> lack thereof cannot be distinguished by smsbox-id alone. >> >> A distributed management is always better than a centralized one as >> complexity scales up, and doesn't limit you to anything in simpler scenarios. >> >> BR, >> Nikos >> >> On Fri, Dec 17, 2010 at 8:50 PM, Alejandro Guerrieri <aguerri...@kannel.org> >> wrote: >> Well, it's a tradeoff, as usual. >> >> If you get a complex cluster of services, usually you either manage them >> altogether (and lose granularity), or manage them individually (and each >> time you need to change something on all of them you need to do it X times). >> >> Now, a good compromise would be to be able to optionally target a specific >> instance by passing the smsbox-id. If you don't pass it, the command is >> delivered to all the connected smsboxes, but if you pass it the command is >> only passed to that specific smsbox instance. >> >> Regards, >> -- >> Alejandro Guerrieri >> aguerri...@kannel.org >> >> On 17/12/2010, at 19:44, Nikos Balkanas wrote: >> >> > Maybe, but it doesn't scale well. Consider that you may have 2-3 smsboxes, >> > an sqlbox and an smppbox (all connected as smsboxes to bb). Next you might >> > want to be able to change dynamically log levels to each one, or >> > dynamically manage sendsms accounts. You will end up with a bb admin page >> > a mile long. Besides, sqlbox has different admin requirements than smppbox >> > or smsbox and bb cannot tell them apart. >> > >> > BR, >> > Nikos >> > ----- Original Message ----- From: Alexander Malysh >> > To: Nikos Balkanas >> > Cc: David McCann ; devel@kannel.org >> > Sent: Friday, December 17, 2010 5:04 PM >> > Subject: Re: Submitting a patch to Kannel: best practices? >> > >> > >> > Hi, >> > >> > >> > it would be better to let bearerbox tell smsbox to reload lists. admin >> > message already exists for communication >> > between bearerbox and smsbox (see restart command as example). >> > >> > >> > Then you don't need extra admin interface for smsbox. >> > >> > >> > Thanks, >> > Alexander Malysh >> > >> > >> > Am 17.12.2010 um 14:49 schrieb Nikos Balkanas: >> > >> > >> > Hi David, >> > >> > >> > >> > Yes. bb has its own black/white lists for incoming MO traffic, similar to >> > smsbox's MT. These can be reloaded on the fly through its http admin >> > interface. Another very useful feature is that it allows you to change >> > log-levels on the fly. Very useful for debugging. >> > >> > >> > Check gw/bb_http.c: httpd_commands for sources. >> > >> > >> > I am not talking about bearerbox telling smsbox to reload its lists. I am >> > talking for a separate http admin for smsbox, like the one in bb. >> > Otherwise you would have major restructuring to get it through the admin >> > *Msg, and it is not worth it. >> > >> > >> > BR, >> > Nikos >> > >> > >> > On Fri, Dec 17, 2010 at 1:07 PM, David McCann <david.a.mcc...@gmail.com> >> > wrote: >> > >> > Hi Nikos-- >> > >> > >> > Thank you for the promt reply! I completely agree that this makes more >> > sense as a bearerbox, admin command. I initially added it as such, but >> > then realized that in fact, all the translations logic sat within the >> > smsbox process, rather than the bearerbox. Adding it directly as an >> > smsbox command removes any need for any communication between the >> > bearerbox and the smsbox. >> > >> > >> > But I agree it still feels like a hack, in terms of where a user would >> > expect to send a command such as "refresh list." If you could point me to >> > a pattern in the code where the bearerbox communicates with the smsbox in >> > a similar fashion, it'd be a huge help and I'd be happy to re-submit my >> > patch with it working in that manner. The current diff is still attached >> > to the feature request, but I've attached it here as well (currently in >> > two patches, src and doc) just for review, as we discuss this alternate >> > approach. >> > >> > >> > In regards to your comment about bearerbox handling this on the fly >> > through its admin HTTP interface...I'm not quite sure I follow? I know >> > this service-level refreshing functionality doesn't currently exist, are >> > you just referring to similar functionality that exists in bearerbox? >> > Forgive my confusion. >> > >> > >> > Thanks again, >> > --dm >> > >> > >> > >> > >> > On Fri, Dec 17, 2010 at 1:07 PM, Nikos Balkanas <nbalka...@gmail.com> >> > wrote: >> > >> > Hi, >> > >> > >> > >> > Usually people just post the patch to the devel list with subject: Patch: >> > <filename>. Patch is attached as a diff of the file(s) from latest svn >> > sources, followed by a brief description in the body. >> > >> > >> > Wrt to your proposed solution, I am not very much in favor. In bearerbox >> > this is handle on the fly through its admin HTTP interface. I think a >> > similar approach would be best for smsbox. >> > >> > >> > BR, >> > Nikos >> > >> > >> > On Fri, Dec 17, 2010 at 8:10 AM, David McCann <david.a.mcc...@gmail.com> >> > wrote: >> > >> > Greetings all! >> > >> > >> > I've been a kannel user for years, but within the past week I've just >> > started to work directly with the code. I had a particular need which I >> > couldn't find a good workaround for: >> > >> > >> > My current deployment with kannel uses whitelisting to dispatch messages >> > to various running web applications (at the sms-service group level), >> > however users do update their contact information from time to time, >> > meaning the whitelist needs to updated, preferrably without the smsbox >> > having to be restarted entirely. >> > >> > >> > I've added a new command to the list of available commands for SMSBox, >> > namely /cgi-bin/refreshlist, and (maybe a little overzealously) created an >> > issue: https://redmine.kannel.org/issues/584 >> > >> > >> > And submitted my patch there. >> > >> > >> > Given that I'm pretty new to this community, I'm wondering if anyone can >> > advise me on the best/most convenient way to submit a patch for >> > incorporation into the code? >> > >> > >> > Thanks in advance, >> > David McCann >> > T4D, UNICEF Uganda >> > >> >> >
