[RFC] New 'box' Kannel Pluginbox

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] New 'box' Kannel Pluginbox

Donald Jackson-6
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?


Thanks Alejandro for SQLBox, its largely based on your code.

Regards,
--
Donald Jackson
http://www.ddj.co.za
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New 'box' Kannel Pluginbox

Kyriacos/Netsmart
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?


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: [hidden email]
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 [hidden email] **
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New 'box' Kannel Pluginbox

Donald Jackson-6
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 <[hidden email]> 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?


Thanks Alejandro for SQLBox, its largely based on your code.

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

-- 
Kyriacos Sakkas
Development Team
Netsmart
Tel: <a href="tel:%2B%20357%2022%20452565" value="+35722452565" target="_blank">+ 357 22 452565
Fax: <a href="tel:%2B%20357%2022%20452566" value="+35722452566" target="_blank">+ 357 22 452566
Email: [hidden email]
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 [hidden email] **



--
Donald Jackson
http://www.ddj.co.za
Reply | Threaded
Open this post in threaded view
|

RE: [RFC] New 'box' Kannel Pluginbox

Rene Kluwen
In reply to this post by Donald Jackson-6

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:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 9:25
Aan: kannel_dev_mailinglist <[hidden email]>
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?

 

 

Thanks Alejandro for SQLBox, its largely based on your code.

 

Regards,

--

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

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New 'box' Kannel Pluginbox

Donald Jackson-6
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 <[hidden email]> 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:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 9:25
Aan: kannel_dev_mailinglist <[hidden email]>
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?

 

 

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
Reply | Threaded
Open this post in threaded view
|

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: [hidden email] [mailto:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 11:26
Aan: Rene Kluwen <[hidden email]>
CC: kannel_dev_mailinglist <[hidden email]>
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 <[hidden email]> 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:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 9:25
Aan: kannel_dev_mailinglist <[hidden email]>
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?

 

 

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

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New 'box' Kannel Pluginbox

Donald Jackson-6
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 11:26
Aan: Rene Kluwen <[hidden email]>
CC: kannel_dev_mailinglist <[hidden email]>
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 <[hidden email]> 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:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 9:25
Aan: kannel_dev_mailinglist <[hidden email]>
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?

 

 

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
Reply | Threaded
Open this post in threaded view
|

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" <[hidden email]> 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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 11:26
Aan: Rene Kluwen <[hidden email]>
CC: kannel_dev_mailinglist <[hidden email]>
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 <[hidden email]> 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:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 9:25
Aan: kannel_dev_mailinglist <[hidden email]>
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?

 

 

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

Reply | Threaded
Open this post in threaded view
|

RE: [RFC] New 'box' Kannel Pluginbox

Rene Kluwen
In reply to this post by Donald Jackson-6

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: [hidden email] [mailto:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 13:02
Aan: Rene Kluwen <[hidden email]>
CC: kannel_dev_mailinglist <[hidden email]>
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 11:26
Aan: Rene Kluwen <[hidden email]>
CC: kannel_dev_mailinglist <[hidden email]>
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 <[hidden email]> 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:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 9:25
Aan: kannel_dev_mailinglist <[hidden email]>
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?

 

 

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

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New 'box' Kannel Pluginbox

Donald Jackson-6
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 13:02


Aan: Rene Kluwen <[hidden email]>
CC: kannel_dev_mailinglist <[hidden email]>
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 11:26
Aan: Rene Kluwen <[hidden email]>
CC: kannel_dev_mailinglist <[hidden email]>
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 <[hidden email]> 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:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 9:25
Aan: kannel_dev_mailinglist <[hidden email]>
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?

 

 

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




--
Donald Jackson
http://www.ddj.co.za
Reply | Threaded
Open this post in threaded view
|

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: [hidden email] [mailto:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 16:42
Aan: Rene Kluwen <[hidden email]>
CC: kannel_dev_mailinglist <[hidden email]>
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 13:02


Aan: Rene Kluwen <[hidden email]>
CC: kannel_dev_mailinglist <[hidden email]>
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 11:26
Aan: Rene Kluwen <[hidden email]>
CC: kannel_dev_mailinglist <[hidden email]>
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 <[hidden email]> 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:[hidden email]] Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 9:25
Aan: kannel_dev_mailinglist <[hidden email]>
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?

 

 

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



 

--

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

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New 'box' Kannel Pluginbox

Donald Jackson-6
In reply to this post by Donald Jackson-6
Hi everyone (again),

Thank you for the great feedback yesterday (publicly and privately).

I have updated the repository here: https://github.com/donald-jackson/kannel-pluginbox

And have included the HTTP plugin as promised with an example of how to modify and reject traffic. If you have any issues please make use of the issue tracker on Github.

I'd also like to correct my mistake of only crediting Alejandro in my original mail - thanks too to Rene actually started SQLBox ;)

Thanks,
Donald

On 6 October 2016 at 09:25, Donald Jackson <[hidden email]> 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?


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
Reply | Threaded
Open this post in threaded view
|

RE: [RFC] New 'box' Kannel Pluginbox

Rene Kluwen

What exactly do the done() and callback() functions in the plugin structure?

Are they required?

 

== Rene

 

Van: devel [mailto:[hidden email]] Namens Donald Jackson
Verzonden: vrijdag 7 oktober 2016 11:50
Aan: kannel_dev_mailinglist <[hidden email]>
Onderwerp: Re: [RFC] New 'box' Kannel Pluginbox

 

Hi everyone (again),

 

Thank you for the great feedback yesterday (publicly and privately).

 

I have updated the repository here: https://github.com/donald-jackson/kannel-pluginbox

 

And have included the HTTP plugin as promised with an example of how to modify and reject traffic. If you have any issues please make use of the issue tracker on Github.

 

I'd also like to correct my mistake of only crediting Alejandro in my original mail - thanks too to Rene actually started SQLBox ;)

 

Thanks,

Donald

 

On 6 October 2016 at 09:25, Donald Jackson <[hidden email]> 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?

 

 

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

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New 'box' Kannel Pluginbox

Donald Jackson-6
Hi Rene,

Yes they are.

The plugins are not executed in a synchronous fashion, they need to call the callback function when they are done processing. This is to allow the plugins to do long running tasks (eg HTTP queries) without slowing down potentially faster message execution chains.

At the end of the plugin chain, the plugin processor will finally call the 'done' callback, which will be different depending on the direction of messages. Plugins only need worry about making sure they call the callback() function in all scenarios, otherwise messages will stall and never be acked/nacked.

You can see in my example HTTP plugin here how to handle an asynchronous execution chain: https://github.com/donald-jackson/kannel-pluginbox/blob/master/plugins/pluginbox_http.c

Hope this helps.

Thanks,
Donald

On 12 October 2016 at 13:48, Rene Kluwen <[hidden email]> wrote:

What exactly do the done() and callback() functions in the plugin structure?

Are they required?

 

== Rene

 

Van: devel [mailto:[hidden email]] Namens Donald Jackson
Verzonden: vrijdag 7 oktober 2016 11:50
Aan: kannel_dev_mailinglist <[hidden email]>
Onderwerp: Re: [RFC] New 'box' Kannel Pluginbox

 

Hi everyone (again),

 

Thank you for the great feedback yesterday (publicly and privately).

 

I have updated the repository here: https://github.com/donald-jackson/kannel-pluginbox

 

And have included the HTTP plugin as promised with an example of how to modify and reject traffic. If you have any issues please make use of the issue tracker on Github.

 

I'd also like to correct my mistake of only crediting Alejandro in my original mail - thanks too to Rene actually started SQLBox ;)

 

Thanks,

Donald

 

On 6 October 2016 at 09:25, Donald Jackson <[hidden email]> 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?

 

 

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
Reply | Threaded
Open this post in threaded view
|

RE: [RFC] New 'box' Kannel Pluginbox

José Héctor Galimberti
In reply to this post by Donald Jackson-6

Hello Donald / Devel list I hope to see this plugin soon on the addon repository of kannel.

 

 

1) Is this something worthwhile doing, does anyone else have a need for this?

 

Yes, i think on at least 2 features that I can do in my current implementation of kannel

 

1.- Dynamic Prefix routing with database, now kannel only accepts regular expressions and that is not enough for all countrys, at least not for Mexico

2.- All sort of dynamic filtering routing features with database configuration without requiring restart or reload of kannel: dynamic SPAM filter / priority switching based on string matching / dynamic blacklisting

 

2) Are there any considerations you wish to add at this time?

 

Only worried about stability / perfomance

 

3) Are there any features you would like to see added?

 

 

4) Would there be any problem including this in the Kannel repository?

 

Hope to see it soon there

 

 



__________ Informaci�n de ESET Smart Security, versi�n de la base de datos de firmas de virus 14300 (20161018) __________

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New 'box' Kannel Pluginbox

Donald Jackson-6
Hi Jose,

Please check out https://github.com/donald-jackson/kannel-pluginbox (read README carefully)

1) If you have an HTTP application that can perform these tasks (routing, etc) you can already do this with pluginbox + the HTTP plugin.

The plugin is written to deal with requests in an asynchronous/callback fashion so it should only be limited by the speed of your HTTP application in terms of performance.

Good luck,
Donald



On 18 October 2016 at 23:56, José Héctor Galimberti <[hidden email]> wrote:

Hello Donald / Devel list I hope to see this plugin soon on the addon repository of kannel.

 

 

1) Is this something worthwhile doing, does anyone else have a need for this?

 

Yes, i think on at least 2 features that I can do in my current implementation of kannel

 

1.- Dynamic Prefix routing with database, now kannel only accepts regular expressions and that is not enough for all countrys, at least not for Mexico

2.- All sort of dynamic filtering routing features with database configuration without requiring restart or reload of kannel: dynamic SPAM filter / priority switching based on string matching / dynamic blacklisting

 

2) Are there any considerations you wish to add at this time?

 

Only worried about stability / perfomance

 

3) Are there any features you would like to see added?

 

 

4) Would there be any problem including this in the Kannel repository?

 

Hope to see it soon there

 

 



__________ Información de ESET Smart Security, versión de la base de datos de firmas de virus 14300 (20161018) __________

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com



--
Donald Jackson
http://www.ddj.co.za
Reply | Threaded
Open this post in threaded view
|

RE: [RFC] New 'box' Kannel Pluginbox

José Héctor Galimberti

Theres a way to measure this parameter, once in production:

 

max-pending-requests=200

 

 

 

De: [hidden email] [mailto:[hidden email]] En nombre de Donald Jackson
Enviado el: Martes, 18 de Octubre de 2016 04:00 p.m.
Para: José Héctor Galimberti
CC: kannel_dev_mailinglist
Asunto: Re: [RFC] New 'box' Kannel Pluginbox

 

Hi Jose,

 

Please check out https://github.com/donald-jackson/kannel-pluginbox (read README carefully)

 

1) If you have an HTTP application that can perform these tasks (routing, etc) you can already do this with pluginbox + the HTTP plugin.

 

The plugin is written to deal with requests in an asynchronous/callback fashion so it should only be limited by the speed of your HTTP application in terms of performance.

 

Good luck,

Donald

 

 

 

On 18 October 2016 at 23:56, José Héctor Galimberti <[hidden email]> wrote:

Hello Donald / Devel list I hope to see this plugin soon on the addon repository of kannel.

 

 

1) Is this something worthwhile doing, does anyone else have a need for this?

 

Yes, i think on at least 2 features that I can do in my current implementation of kannel

 

1.- Dynamic Prefix routing with database, now kannel only accepts regular expressions and that is not enough for all countrys, at least not for Mexico

2.- All sort of dynamic filtering routing features with database configuration without requiring restart or reload of kannel: dynamic SPAM filter / priority switching based on string matching / dynamic blacklisting

 

2) Are there any considerations you wish to add at this time?

 

Only worried about stability / perfomance

 

3) Are there any features you would like to see added?

 

 

4) Would there be any problem including this in the Kannel repository?

 

Hope to see it soon there

 

 



__________ Información de ESET Smart Security, versión de la base de datos de firmas de virus 14300 (20161018) __________

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com



 

--

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



__________ Informaci�n de ESET Smart Security, versi�n de la base de datos de firmas de virus 14301 (20161018) __________

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New 'box' Kannel Pluginbox

Donald Jackson-6
Sorry I don't understand what you mean

On Wednesday, 19 October 2016, José Héctor Galimberti <[hidden email]> wrote:

Theres a way to measure this parameter, once in production:

 

max-pending-requests=200

 

 

 

De: <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;donaldjster@gmail.com&#39;);" target="_blank">donaldjster@... [mailto:<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;donaldjster@gmail.com&#39;);" target="_blank">donaldjster@...] En nombre de Donald Jackson
Enviado el: Martes, 18 de Octubre de 2016 04:00 p.m.
Para: José Héctor Galimberti
CC: kannel_dev_mailinglist
Asunto: Re: [RFC] New 'box' Kannel Pluginbox

 

Hi Jose,

 

Please check out https://github.com/donald-jackson/kannel-pluginbox (read README carefully)

 

1) If you have an HTTP application that can perform these tasks (routing, etc) you can already do this with pluginbox + the HTTP plugin.

 

The plugin is written to deal with requests in an asynchronous/callback fashion so it should only be limited by the speed of your HTTP application in terms of performance.

 

Good luck,

Donald

 

 

 

On 18 October 2016 at 23:56, José Héctor Galimberti <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ingenieria@conexioncelular.com.mx&#39;);" target="_blank">ingenieria@conexioncelular.com.mx> wrote:

Hello Donald / Devel list I hope to see this plugin soon on the addon repository of kannel.

 

 

1) Is this something worthwhile doing, does anyone else have a need for this?

 

Yes, i think on at least 2 features that I can do in my current implementation of kannel

 

1.- Dynamic Prefix routing with database, now kannel only accepts regular expressions and that is not enough for all countrys, at least not for Mexico

2.- All sort of dynamic filtering routing features with database configuration without requiring restart or reload of kannel: dynamic SPAM filter / priority switching based on string matching / dynamic blacklisting

 

2) Are there any considerations you wish to add at this time?

 

Only worried about stability / perfomance

 

3) Are there any features you would like to see added?

 

 

4) Would there be any problem including this in the Kannel repository?

 

Hope to see it soon there

 

 



__________ Información de ESET Smart Security, versión de la base de datos de firmas de virus 14300 (20161018) __________

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com



 

--

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



__________ Información de ESET Smart Security, versión de la base de datos de firmas de virus 14301 (20161018) __________

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com


--

Reply | Threaded
Open this post in threaded view
|

RE: [RFC] New 'box' Kannel Pluginbox

José Héctor Galimberti

I mean, once system its working, there s a way to measure how many pending request are there? What will happened with request number 201 it will get rejected / retry latter?

 

 

De: [hidden email] [mailto:[hidden email]] En nombre de Donald Jackson
Enviado el: Miércoles, 19 de Octubre de 2016 05:09 a.m.
Para: José Héctor Galimberti
CC: kannel_dev_mailinglist
Asunto: Re: [RFC] New 'box' Kannel Pluginbox

 

Sorry I don't understand what you mean

On Wednesday, 19 October 2016, José Héctor Galimberti <[hidden email]> wrote:

Theres a way to measure this parameter, once in production:

 

max-pending-requests=200

 

 

 

De: <a href="javascript:_e(%7B%7D,'cvml','donaldjster@gmail.com');" target="_blank">donaldjster@... [mailto:<a href="javascript:_e(%7B%7D,'cvml','donaldjster@gmail.com');" target="_blank">donaldjster@...] En nombre de Donald Jackson
Enviado el: Martes, 18 de Octubre de 2016 04:00 p.m.
Para: José Héctor Galimberti
CC: kannel_dev_mailinglist
Asunto: Re: [RFC] New 'box' Kannel Pluginbox

 

Hi Jose,

 

Please check out https://github.com/donald-jackson/kannel-pluginbox (read README carefully)

 

1) If you have an HTTP application that can perform these tasks (routing, etc) you can already do this with pluginbox + the HTTP plugin.

 

The plugin is written to deal with requests in an asynchronous/callback fashion so it should only be limited by the speed of your HTTP application in terms of performance.

 

Good luck,

Donald

 

 

 

On 18 October 2016 at 23:56, José Héctor Galimberti <<a href="javascript:_e(%7B%7D,'cvml','ingenieria@conexioncelular.com.mx');" target="_blank">ingenieria@...> wrote:

Hello Donald / Devel list I hope to see this plugin soon on the addon repository of kannel.

 

 

1) Is this something worthwhile doing, does anyone else have a need for this?

 

Yes, i think on at least 2 features that I can do in my current implementation of kannel

 

1.- Dynamic Prefix routing with database, now kannel only accepts regular expressions and that is not enough for all countrys, at least not for Mexico

2.- All sort of dynamic filtering routing features with database configuration without requiring restart or reload of kannel: dynamic SPAM filter / priority switching based on string matching / dynamic blacklisting

 

2) Are there any considerations you wish to add at this time?

 

Only worried about stability / perfomance

 

3) Are there any features you would like to see added?

 

 

4) Would there be any problem including this in the Kannel repository?

 

Hope to see it soon there

 

 



__________ Información de ESET Smart Security, versión de la base de datos de firmas de virus 14300 (20161018) __________

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com



 

--

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



__________ Información de ESET Smart Security, versión de la base de datos de firmas de virus 14301 (20161018) __________

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com



--



__________ Informaci�n de ESET Smart Security, versi�n de la base de datos de firmas de virus 14306 (20161019) __________

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New 'box' Kannel Pluginbox

Donald Jackson-6
Currently no way of checking that at runtime, but it would be easy enough to add logs to show. I will also consider pull requests if you wish to contribute.

Once it hits the pending number it just waits until there is 'space' and continues.



On 19 October 2016 at 19:43, José Héctor Galimberti <[hidden email]> wrote:

I mean, once system its working, there s a way to measure how many pending request are there? What will happened with request number 201 it will get rejected / retry latter?

 

 

De: [hidden email] [mailto:[hidden email]] En nombre de Donald Jackson
Enviado el: Miércoles, 19 de Octubre de 2016 05:09 a.m.


Para: José Héctor Galimberti
CC: kannel_dev_mailinglist
Asunto: Re: [RFC] New 'box' Kannel Pluginbox

 

Sorry I don't understand what you mean

On Wednesday, 19 October 2016, José Héctor Galimberti <[hidden email]> wrote:

Theres a way to measure this parameter, once in production:

 

max-pending-requests=200

 

 

 

De: [hidden email] [mailto:[hidden email]] En nombre de Donald Jackson
Enviado el: Martes, 18 de Octubre de 2016 04:00 p.m.
Para: José Héctor Galimberti
CC: kannel_dev_mailinglist
Asunto: Re: [RFC] New 'box' Kannel Pluginbox

 

Hi Jose,

 

Please check out https://github.com/donald-jackson/kannel-pluginbox (read README carefully)

 

1) If you have an HTTP application that can perform these tasks (routing, etc) you can already do this with pluginbox + the HTTP plugin.

 

The plugin is written to deal with requests in an asynchronous/callback fashion so it should only be limited by the speed of your HTTP application in terms of performance.

 

Good luck,

Donald

 

 

 

On 18 October 2016 at 23:56, José Héctor Galimberti <ingenieria@conexioncelular.com.mx> wrote:

Hello Donald / Devel list I hope to see this plugin soon on the addon repository of kannel.

 

 

1) Is this something worthwhile doing, does anyone else have a need for this?

 

Yes, i think on at least 2 features that I can do in my current implementation of kannel

 

1.- Dynamic Prefix routing with database, now kannel only accepts regular expressions and that is not enough for all countrys, at least not for Mexico

2.- All sort of dynamic filtering routing features with database configuration without requiring restart or reload of kannel: dynamic SPAM filter / priority switching based on string matching / dynamic blacklisting

 

2) Are there any considerations you wish to add at this time?

 

Only worried about stability / perfomance

 

3) Are there any features you would like to see added?

 

 

4) Would there be any problem including this in the Kannel repository?

 

Hope to see it soon there

 

 



__________ Información de ESET Smart Security, versión de la base de datos de firmas de virus 14300 (20161018) __________

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com



 

--

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



__________ Información de ESET Smart Security, versión de la base de datos de firmas de virus 14301 (20161018) __________

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com



--



__________ Información de ESET Smart Security, versión de la base de datos de firmas de virus 14306 (20161019) __________

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com



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