Hi,
First thought, yep would be really useful as for me it would allow
removing the (or at least some) sms routing logic from the backend
application and keep it within kannel, where it logically fits better.
Additional thoughts:
1) Although HTTP as the initial plugin provides something straight
forward for all to use, I would find very useful if in addition there
was some (XML?) rules plugin. I can elaborate on it if you wish.
Unfortunately my skills would only let me build it as something that can
be called via HTTP right now, which is at least ironic :) .
2) Have the ability (via a config parameter to activate) to cache
responses from the various plugins. A pluggin might need to read for
example only keyword and destination address. An in memory hash table of
the X most recent (or time limited) queries will have a huge speed boost
to many traffic patterns, especially if the plugin is something that
makes an external call or must be launched per request.
Thanks,
Kyriacos
On 06/10/2016 10:25, Donald Jackson wrote:
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 <http://www.ddj.co.za/>
--
Kyriacos Sakkas
Development Team
Netsmart
Tel: + 357 22 452565
Fax: + 357 22 452566
Email: [email protected]
http://www.netsmart.com.cy
Taking Business to a New Level!
** Confidentiality Notice: The information contained in this email
message may be privileged, confidential and protected from disclosure.
If you are not the intended recipient, any dissemination, distribution,
or copying of this email message is strictly prohibited.
If you think that you have received this email message in error, please
email the sender at [email protected] **
