Wow, well this was fun and productive. I guess I should be happy I've at least created a feature that I can use, and sparked some really fun-to-listen-in-on bickering.
I can't find the portion in the code where bearerbox actually sends a signal to smsbox anyway (from the best I can figure out looking at doxygen, bb just shuts down, and smsbox polls for that to happen), so I think it would definitely be a serious refactoring (beyond my allotted time and willingness to go dig into the code) to do it in the way that I *think* you've talking about...although honestly, at this point I can't really follow what's being argued. There doesn't seem to be any real interest in adding this feature, regardless of how it's added. Good luck, --dm On Sat, Dec 18, 2010 at 8:47 PM, Alejandro Guerrieri <aguerri...@kannel.org>wrote: > Sure, go maintain it yourself manually on a set of thousands of nodes. > > The easiest thing is to let the _system_ keep track of its registered > resources and provide you with that list. > > Go check how most clustered systems work, I bet you won't find many > requiring the administrator to create a wiki page with the urls. > -- > Alejandro Guerrieri > aguerri...@kannel.org > > > > On 18/12/2010, at 18:40, Nikos Balkanas wrote: > > Besides, in a distributed administration system, the easiest thing is to > have a custom page with links to each system, therefore, so that everything > is managed from a centralized URL. > > BR, > Nikos > > On Sat, Dec 18, 2010 at 7:34 PM, Nikos Balkanas <nbalka...@gmail.com>wrote: > >> No, it won't. smsbox-admin-id is no better than smsbox-id for this >> purpose. In terms of software it doesn't tell anything more to bb, to >> differentiate sqlbox from smppbox or a regular smsbox connection, so that it >> can show different configuration options for each one. >> >> I have also adequate experience with clusters, farms and distributed >> computing. Kannel will have to rewrite major portions of its interface to be >> used in such. >> >> I think that we have just about exhausted this topic. >> >> BR, >> Nikos >> >> On Sat, Dec 18, 2010 at 4:02 PM, Alejandro Guerrieri < >> aguerri...@kannel.org> wrote: >> >>> 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 >>>> > >>>> >>>> >>> >>> >> > >
