RE: [RFC] New 'box' Kannel Pluginbox

[Rene Kluwen]

I’ll see what I can do. It’s a great initiative!

Having said that… I don’t have much time. So it may take a while.

 

Van: donaldjs...@gmail.com [mailto:donaldjs...@gmail.com] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 16:42
Aan: Rene Kluwen 
CC: kannel_dev_mailinglist 
Onderwerp: Re: [RFC] New 'box' Kannel Pluginbox

 

That could be possible too, we would just need to expose some methods for 
injection of messages from the plugins.

 

Currently the only mechanisms they have are event driven (on Msg received from 
a Box) - we would need one that you could manually inject from the database 
tables at a non-event time.

 

Pull requests welcome :D

 

On 6 October 2016 at 16:25, Rene Kluwen  > wrote:

True, you are right.

“Your” plugins are generally more abstracted. Which is better.

 

Another thing that I was thinking about: Sqlbox can be converted to a plugin. 
No need for an extra box anymore.

 

== Rene

 

 

Van: donaldjs...@gmail.com   
[mailto:donaldjs...@gmail.com  ] Namens Donald 
Jackson
Verzonden: donderdag 6 oktober 2016 13:02


Aan: Rene Kluwen  >
CC: kannel_dev_mailinglist  >
Onderwerp: Re: [RFC] New 'box' Kannel Pluginbox

 

Hi Rene,

 

OK. I am familiar with SMPPBox (have written plugins too ;)) which is why I was 
wondering. The 'problem' with this would be that SMPPBox plugin architecture 
functions on PDUs (submit_sm, deliver_sm, data_sm etc) and not Msg * 
structures, so in order to make the plugins compatible it would need to convert 
messages to and from PDU structs's which may not be an ideal architecture at 
this layer. It also wouldn't be able to deal with authentication (bind_* PDUs) 
as SMPPBox does at the plugin level.

 

Of course if someone else needs this they can write a plugin to do these 
conversions and process :) 

 

Thanks,

Donald

 

 

 

On 6 October 2016 at 12:50, Rene Kluwen  > wrote:

This is more Stipe’s area.

But his smppbox uses a plugin structure as well.

If you use the same structure, people can upgrade/downgrade between smppbox 
server and opensmppbox while maintaining plugin compatibility.

 

== Rene

 

Van: donaldjs...@gmail.com   
[mailto:donaldjs...@gmail.com  ] Namens Donald 
Jackson
Verzonden: donderdag 6 oktober 2016 11:26
Aan: Rene Kluwen  >
CC: kannel_dev_mailinglist  >
Onderwerp: Re: [RFC] New 'box' Kannel Pluginbox

 

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  > 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  >
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 

Re: [RFC] New 'box' Kannel Pluginbox

[Donald Jackson]

That could be possible too, we would just need to expose some methods for
injection of messages from the plugins.

Currently the only mechanisms they have are event driven (on Msg received
from a Box) - we would need one that you could manually inject from the
database tables at a non-event time.

Pull requests welcome :D

On 6 October 2016 at 16:25, Rene Kluwen  wrote:

> True, you are right.
>
> “Your” plugins are generally more abstracted. Which is better.
>
>
>
> Another thing that I was thinking about: Sqlbox can be converted to a
> plugin. No need for an extra box anymore.
>
>
>
> == Rene
>
>
>
>
>
> *Van:* donaldjs...@gmail.com [mailto:donaldjs...@gmail.com] *Namens *Donald
> Jackson
> *Verzonden:* donderdag 6 oktober 2016 13:02
>
> *Aan:* Rene Kluwen 
> *CC:* kannel_dev_mailinglist 
> *Onderwerp:* Re: [RFC] New 'box' Kannel Pluginbox
>
>
>
> Hi Rene,
>
>
>
> OK. I am familiar with SMPPBox (have written plugins too ;)) which is why
> I was wondering. The 'problem' with this would be that SMPPBox plugin
> architecture functions on PDUs (submit_sm, deliver_sm, data_sm etc) and not
> Msg * structures, so in order to make the plugins compatible it would need
> to convert messages to and from PDU structs's which may not be an ideal
> architecture at this layer. It also wouldn't be able to deal with
> authentication (bind_* PDUs) as SMPPBox does at the plugin level.
>
>
>
> Of course if someone else needs this they can write a plugin to do these
> conversions and process :)
>
>
>
> Thanks,
>
> Donald
>
>
>
>
>
>
>
> On 6 October 2016 at 12:50, Rene Kluwen  wrote:
>
> This is more Stipe’s area.
>
> But his smppbox uses a plugin structure as well.
>
> If you use the same structure, people can upgrade/downgrade between
> smppbox server and opensmppbox while maintaining plugin compatibility.
>
>
>
> == Rene
>
>
>
> *Van:* donaldjs...@gmail.com [mailto:donaldjs...@gmail.com] *Namens *Donald
> Jackson
> *Verzonden:* donderdag 6 oktober 2016 11:26
> *Aan:* Rene Kluwen 
> *CC:* kannel_dev_mailinglist 
> *Onderwerp:* Re: [RFC] New 'box' Kannel Pluginbox
>
>
>
> 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  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 
> *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 

RE: [RFC] New 'box' Kannel Pluginbox

[Rene Kluwen]

True, you are right.

“Your” plugins are generally more abstracted. Which is better.

 

Another thing that I was thinking about: Sqlbox can be converted to a plugin. 
No need for an extra box anymore.

 

== Rene

 

 

Van: donaldjs...@gmail.com [mailto:donaldjs...@gmail.com] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 13:02
Aan: Rene Kluwen 
CC: kannel_dev_mailinglist 
Onderwerp: Re: [RFC] New 'box' Kannel Pluginbox

 

Hi Rene,

 

OK. I am familiar with SMPPBox (have written plugins too ;)) which is why I was 
wondering. The 'problem' with this would be that SMPPBox plugin architecture 
functions on PDUs (submit_sm, deliver_sm, data_sm etc) and not Msg * 
structures, so in order to make the plugins compatible it would need to convert 
messages to and from PDU structs's which may not be an ideal architecture at 
this layer. It also wouldn't be able to deal with authentication (bind_* PDUs) 
as SMPPBox does at the plugin level.

 

Of course if someone else needs this they can write a plugin to do these 
conversions and process :) 

 

Thanks,

Donald

 

 

 

On 6 October 2016 at 12:50, Rene Kluwen  > wrote:

This is more Stipe’s area.

But his smppbox uses a plugin structure as well.

If you use the same structure, people can upgrade/downgrade between smppbox 
server and opensmppbox while maintaining plugin compatibility.

 

== Rene

 

Van: donaldjs...@gmail.com   
[mailto:donaldjs...@gmail.com  ] Namens Donald 
Jackson
Verzonden: donderdag 6 oktober 2016 11:26
Aan: Rene Kluwen  >
CC: kannel_dev_mailinglist  >
Onderwerp: Re: [RFC] New 'box' Kannel Pluginbox

 

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  > 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  >
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
 

Re: [RFC] New 'box' Kannel Pluginbox

[Hanh Le Bich]

I wish i can use this box to filter SMS by content or even other polices,
it is a kind of SMS firewall. Many thanks.

Cheers,
Hanh.

On Oct 6, 2016 18:02, "Donald Jackson"  wrote:

Hi Rene,

OK. I am familiar with SMPPBox (have written plugins too ;)) which is why I
was wondering. The 'problem' with this would be that SMPPBox plugin
architecture functions on PDUs (submit_sm, deliver_sm, data_sm etc) and not
Msg * structures, so in order to make the plugins compatible it would need
to convert messages to and from PDU structs's which may not be an ideal
architecture at this layer. It also wouldn't be able to deal with
authentication (bind_* PDUs) as SMPPBox does at the plugin level.

Of course if someone else needs this they can write a plugin to do these
conversions and process :)

Thanks,
Donald



On 6 October 2016 at 12:50, Rene Kluwen  wrote:

> This is more Stipe’s area.
>
> But his smppbox uses a plugin structure as well.
>
> If you use the same structure, people can upgrade/downgrade between
> smppbox server and opensmppbox while maintaining plugin compatibility.
>
>
>
> == Rene
>
>
>
> *Van:* donaldjs...@gmail.com [mailto:donaldjs...@gmail.com] *Namens *Donald
> Jackson
> *Verzonden:* donderdag 6 oktober 2016 11:26
> *Aan:* Rene Kluwen 
> *CC:* kannel_dev_mailinglist 
> *Onderwerp:* Re: [RFC] New 'box' Kannel Pluginbox
>
>
>
> 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  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 
> *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-ja
> ckson/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
>



-- 
Donald Jackson
http://www.ddj.co.za

Re: [RFC] New 'box' Kannel Pluginbox

[Donald Jackson]

Hi Rene,

OK. I am familiar with SMPPBox (have written plugins too ;)) which is why I
was wondering. The 'problem' with this would be that SMPPBox plugin
architecture functions on PDUs (submit_sm, deliver_sm, data_sm etc) and not
Msg * structures, so in order to make the plugins compatible it would need
to convert messages to and from PDU structs's which may not be an ideal
architecture at this layer. It also wouldn't be able to deal with
authentication (bind_* PDUs) as SMPPBox does at the plugin level.

Of course if someone else needs this they can write a plugin to do these
conversions and process :)

Thanks,
Donald



On 6 October 2016 at 12:50, Rene Kluwen  wrote:

> This is more Stipe’s area.
>
> But his smppbox uses a plugin structure as well.
>
> If you use the same structure, people can upgrade/downgrade between
> smppbox server and opensmppbox while maintaining plugin compatibility.
>
>
>
> == Rene
>
>
>
> *Van:* donaldjs...@gmail.com [mailto:donaldjs...@gmail.com] *Namens *Donald
> Jackson
> *Verzonden:* donderdag 6 oktober 2016 11:26
> *Aan:* Rene Kluwen 
> *CC:* kannel_dev_mailinglist 
> *Onderwerp:* Re: [RFC] New 'box' Kannel Pluginbox
>
>
>
> 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  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 
> *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
>



-- 
Donald Jackson
http://www.ddj.co.za

RE: [RFC] New 'box' Kannel Pluginbox

[Rene Kluwen]

This is more Stipe’s area.

But his smppbox uses a plugin structure as well.

If you use the same structure, people can upgrade/downgrade between smppbox 
server and opensmppbox while maintaining plugin compatibility.

 

== Rene

 

Van: donaldjs...@gmail.com [mailto:donaldjs...@gmail.com] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 11:26
Aan: Rene Kluwen 
CC: kannel_dev_mailinglist 
Onderwerp: Re: [RFC] New 'box' Kannel Pluginbox

 

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  > 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  >
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

Re: [RFC] New 'box' Kannel Pluginbox

[Donald Jackson]

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  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 
> *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

RE: [RFC] New 'box' Kannel Pluginbox

[Rene Kluwen]

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 
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

Re: [RFC] New 'box' Kannel Pluginbox

[Donald Jackson]

Hi Kyriacos,

Thanks for your comments, in response:

1) The purpose of the 'initial' plugin is not to provide any specific
feature, but to demonstrate how to implement a plugin and how to modify all
fields of a message packet. If you (or another person) wished to build an
XML router this would be perfectly possible.

2) As per 1), caching and all other implementation specifics could be done
inside the plugin. Eg if someone wanted to cache URL responses they could
do so, or cache routing for a specific service or number they could do so,
the possibilities are not limited :)

Thanks,
Donald

On 6 October 2016 at 09:44, Kyriacos Sakkas 
wrote:

> 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
>
>
> --
> Kyriacos Sakkas
> Development Team
> Netsmart
> Tel: + 357 22 452565
> Fax: + 357 22 452566
> Email: kyria...@netsmart.com.cyhttp://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 kyria...@netsmart.com.cy **
>
>


-- 
Donald Jackson
http://www.ddj.co.za

Re: [RFC] New 'box' Kannel Pluginbox

[Kyriacos Sakkas]

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 


--
Kyriacos Sakkas
Development Team
Netsmart
Tel: + 357 22 452565
Fax: + 357 22 452566
Email: kyria...@netsmart.com.cy
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 kyria...@netsmart.com.cy **

[RFC] New 'box' Kannel Pluginbox

[Donald Jackson]

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