Hi Rene, Glad to have saved you some work :)
Could you explain what you mean about making it compatible with SMPPBox plugin architecture? Thanks, Donald On 6 October 2016 at 10:55, Rene Kluwen <rene.klu...@chimit.nl> wrote: > Yeah, I think it’s useful. > > Mainly to prevent having a chain of many boxes if you want some extra > functionality. > > In fact, just now I was thinking of making such a box. So you saved me > some work. > > > > Tip: Maybe you can make it source-code compatible with the smppbox server > plugin architecture. > > > > == Rene > > > > > > *Van:* devel [mailto:devel-boun...@kannel.org] *Namens *Donald Jackson > *Verzonden:* donderdag 6 oktober 2016 9:25 > *Aan:* kannel_dev_mailinglist <devel@kannel.org> > *Onderwerp:* [RFC] New 'box' Kannel Pluginbox > > > > Hi everyone, > > > > I have started laying the foundations for a new 'box' for Kannel which > intends to allow users more flexibility in terms of the platform. > > > > At the moment there are many ways to get messages into the bearerbox, > namely: smsbox, wapbox, opensmppbox, smppbox, ksmppd, sqlbox. Some rely on > routing in their own process and others allow bearerbox to do the routing. > What they all have in common is they don't allow external or third party > applications help make decisions at processing time (with the exception of > ksmppd/smppbox). > > > > My new planned box is called pluginbox which will basically be like SQLBox > - but instead of using database callbacks, it will allow linking of dynamic > libraries (.so|.dylib) which will allow custom > interception/filtering/modification > of message packages to and from various boxes. > > > > So a hypothetical scenario for this box could be something like > > > > SMSBox, SMPPBox/KSMPPD, WapBox <--> PluginBox <--> Bearerbox > > > > Or even > > > > SMSBox, SMPPBox/KSMPPD, WapBox <--> SQLBox <--> PluginBox <--> Bearerbox > > > > For those who want to still make use of SQLBox. > > > > My initial design is to use an asynchronous callback chain to allow slow > plugins to not hold up the processing of faster messages. This would be > especially useful in the context of people using HTTP and other external > services to process routing decisions. The plugin would also be able to > return a status to 'reject' a message packet which would in turn not submit > to the target receiver. > > > > My plan is also to implement at least one example plugin (probably an HTTP > plugin?) which can show the submission and manipulation of a message packet > in both directions. > > > > So here I am looking for comments. > > > > 1) Is this something worthwhile doing, does anyone else have a need for > this? > > 2) Are there any considerations you wish to add at this time? > > 3) Are there any features you would like to see added? > > 4) Would there be any problem including this in the Kannel repository? > > > > Here is the initial version : https://github.com/donald- > jackson/kannel-pluginbox > > > > Thanks Alejandro for SQLBox, its largely based on your code. > > > > Regards, > > -- > > Donald Jackson > http://www.ddj.co.za > -- Donald Jackson http://www.ddj.co.za
