Re: [RFC] New 'box' Kannel Pluginbox

[Donald Jackson]

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 <
ingenie...@conexioncelular.com.mx> 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:* donaldjs...@gmail.com [mailto:donaldjs...@gmail.com] *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 <
> ingenie...@conexioncelular.com.mx> wrote:
>
> Theres a way to measure this parameter, once in production:
>
>
>
> max-pending-requests=200
>
>
>
>
>
>
>
> *De:* donaldjs...@gmail.com [mailto:donaldjs...@gmail.com] *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 <
> ingenie...@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

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: donaldjs...@gmail.com [mailto:donaldjs...@gmail.com] 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 
<ingenie...@conexioncelular.com.mx> wrote:

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

 

max-pending-requests=200

 

 

 

De: donaldjs...@gmail.com 
<javascript:_e(%7B%7D,'cvml','donaldjs...@gmail.com');>  
[mailto:donaldjs...@gmail.com 
<javascript:_e(%7B%7D,'cvml','donaldjs...@gmail.com');> ] 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 
<ingenie...@conexioncelular.com.mx 
<javascript:_e(%7B%7D,'cvml','ingenie...@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/> 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



-- 



__ Informacin de ESET Smart Security, versin de la base de datos de 
firmas de virus 14306 (20161019) __

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com

Re: [RFC] New 'box' Kannel Pluginbox

[Donald Jackson]

Sorry I don't understand what you mean

On Wednesday, 19 October 2016, José Héctor Galimberti <
ingenie...@conexioncelular.com.mx> wrote:

> Theres a way to measure this parameter, once in production:
>
>
>
> max-pending-requests=200
>
>
>
>
>
>
>
> *De:* donaldjs...@gmail.com
> <javascript:_e(%7B%7D,'cvml','donaldjs...@gmail.com');> [mailto:
> donaldjs...@gmail.com
> <javascript:_e(%7B%7D,'cvml','donaldjs...@gmail.com');>] *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 <
> ingenie...@conexioncelular.com.mx
> <javascript:_e(%7B%7D,'cvml','ingenie...@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
>


--

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: donaldjs...@gmail.com [mailto:donaldjs...@gmail.com] 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 
<ingenie...@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/> http://www.ddj.co.za



__ Informacin de ESET Smart Security, versin de la base de datos de 
firmas de virus 14301 (20161018) __

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com

Re: [RFC] New 'box' Kannel Pluginbox

[Donald Jackson]

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 <
ingenie...@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

RE: [RFC] New 'box' Kannel Pluginbox

[José Héctor Galimberti]

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

 

 



__ Informacin de ESET Smart Security, versin de la base de datos de 
firmas de virus 14300 (20161018) __

El mensaje fue verificado por ESET Smart Security.

http://www.eset-la.com

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:devel-boun...@kannel.org] Namens Donald Jackson
Verzonden: vrijdag 7 oktober 2016 11:50
Aan: kannel_dev_mailinglist <devel@kannel.org>
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 <djack...@kannel.org 
<mailto:djack...@kannel.org> > wrote:

Hi everyone,

 

I have started laying the foundations for a new 'box' for Kannel which intends 
to allow users more flexibility in terms of the platform.

 

At the moment there are many ways to get messages into the bearerbox, namely: 
smsbox, wapbox, opensmppbox, smppbox, ksmppd, sqlbox. Some rely on routing in 
their own process and others allow bearerbox to do the routing. What they all 
have in common is they don't allow external or third party applications help 
make decisions at processing time (with the exception of ksmppd/smppbox). 

 

My new planned box is called pluginbox which will basically be like SQLBox - 
but instead of using database callbacks, it will allow linking of dynamic 
libraries (.so|.dylib) which will allow custom 
interception/filtering/modification of message packages to and from various 
boxes.

 

So a hypothetical scenario for this box could be something like

 

SMSBox, SMPPBox/KSMPPD, WapBox <--> PluginBox <--> Bearerbox

 

Or even

 

SMSBox, SMPPBox/KSMPPD, WapBox <--> SQLBox <--> PluginBox <--> Bearerbox

 

For those who want to still make use of SQLBox.

 

My initial design is to use an asynchronous callback chain to allow slow 
plugins to not hold up the processing of faster messages. This would be 
especially useful in the context of people using HTTP and other external 
services to process routing decisions. The plugin would also be able to return 
a status to 'reject' a message packet which would in turn not submit to the 
target receiver.

 

My plan is also to implement at least one example plugin (probably an HTTP 
plugin?) which can show the submission and manipulation of a message packet in 
both directions.

 

So here I am looking for comments.

 

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

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

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

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

 

Here is the initial version : https://github.com/donald-jackson/kannel-pluginbox

 

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

 

Regards,

-- 

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





 

-- 

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

Re: [RFC] New 'box' Kannel Pluginbox

[Donald Jackson]

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



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

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 <rene.klu...@chimit.nl>
CC: kannel_dev_mailinglist <devel@kannel.org>
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 <rene.klu...@chimit.nl 
<mailto:rene.klu...@chimit.nl> > 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>  
[mailto:donaldjs...@gmail.com <mailto:donaldjs...@gmail.com> ] Namens Donald 
Jackson
Verzonden: donderdag 6 oktober 2016 13:02


Aan: Rene Kluwen <rene.klu...@chimit.nl <mailto:rene.klu...@chimit.nl> >
CC: kannel_dev_mailinglist <devel@kannel.org <mailto:devel@kannel.org> >
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 <rene.klu...@chimit.nl 
<mailto:rene.klu...@chimit.nl> > 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>  
[mailto:donaldjs...@gmail.com <mailto:donaldjs...@gmail.com> ] Namens Donald 
Jackson
Verzonden: donderdag 6 oktober 2016 11:26
Aan: Rene Kluwen <rene.klu...@chimit.nl <mailto:rene.klu...@chimit.nl> >
CC: kannel_dev_mailinglist <devel@kannel.org <mailto:devel@kannel.org> >
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 <rene.klu...@chimit.nl 
<mailto:rene.klu...@chimit.nl> > wrote:

Yeah, I think it’s useful.

Mainly to prevent having a chain of many boxes if you want some extra 
functionality.

In fact, just now I was thinking of making such a box. So you saved me some 
work.

 

Tip: Maybe you can make it source-code compatible with the smppbox server 
plugin architecture.

 

== Rene

 

 

Van: devel [mailto:devel-boun...@kannel.org <mailto:devel-boun...@kannel.org> ] 
Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 9:25
Aan: kannel_dev_mailinglist <devel@kannel.org <mailto:devel@kannel.org> >
Onderwerp: [RFC] New 'box' Kannel Pluginbox

 

Hi everyone,

 

I have started laying the foundations for a new 'box' for Kannel which intends 
to allow users more flexibility in terms of the platform.

 

At the moment there are many ways to get messages into the bearerbox, namely: 
smsbox, wapbox, opensmppbox, smppbox, ksmppd, sqlbox. Some rely on routing in 
their own process and others allow bearerbox to do the routing. What they all 
have in common is they don't allow external or third party applications help 
make decisions at processing time (with the exception of ksmppd/smppbox). 

 

My new planned box is called pluginbox which will basically be like SQLBox - 
but instead of using database callbacks, it will allow linking of dynamic 
libraries (.so|.dylib) which will allow custom 
interception/filtering/modification of message packages to and from various 
boxes.

 

So a hypothetical scenario for this box could be something like

 

SMSBox, SMPPBox/KSMPPD, WapBox <--> PluginBox <--> Bearerbox

 

Or even

 

SMSBox, SMPPBox/KSMPPD, WapBox <--> SQLBox <--> PluginBox <--> Bearerbox

 

For those who want to still make use of SQLBox.

 

My initial design is to use an asynchronou

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 <rene.klu...@chimit.nl> 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 <rene.klu...@chimit.nl>
> *CC:* kannel_dev_mailinglist <devel@kannel.org>
> *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 <rene.klu...@chimit.nl> 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 <rene.klu...@chimit.nl>
> *CC:* kannel_dev_mailinglist <devel@kannel.org>
> *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 <rene.klu...@chimit.nl> wrote:
>
> Yeah, I think it’s useful.
>
> Mainly to prevent having a chain of many boxes if you want some extra
> functionality.
>
> In fact, just now I was thinking of making such a box. So you saved me
> some work.
>
>
>
> Tip: Maybe you can make it source-code compatible with the smppbox server
> plugin architecture.
>
>
>
> == Rene
>
>
>
>
>
> *Van:* devel [mailto:devel-boun...@kannel.org] *Namens *Donald Jackson
> *Verzonden:* donderdag 6 oktober 2016 9:25
> *Aan:* kannel_dev_mailinglist <devel@kannel.org>
> *Onderwerp:* [RFC] New 'box' Kannel Pluginbox
>
>
>
> Hi everyone,
>
>
>
> I have started laying the foundations for a new 'box' for Kannel which
> intends to allow users more flexibility in terms of the platform.
>
>
>
> At the moment there are many ways to get messages into the bearerbox,
> namely: smsbox, wapbox, opensmppbox, smppbox, ksmppd, sqlbox. Some rely on
> routing in their own process and others allow bearerbox to do the routing.
> What they all have in common is they don't allow external or third party
> applications help make decisions at processing time (with the exception of
> ksmppd/smppbox).
>
>
>
> My new planned box is called pluginbox which will basically be like SQLBox
> - but instead of using database callbacks, it will allow linking of dynamic
> libraries (.so|.dylib) which will allow custom 
> interception/filtering/modification
> of message packages to and from various boxes.
>
>
>
> So a hypothetical scenario for this box could be something like
>
>
>
> SMSBox, SMPPBox/KSMPPD, WapBox <--> PluginBox <--> Bearerbox
>
>
>
> Or even
>
>
>
> SMSBox, SMPPBox/KSMPPD, WapBox <--> SQLBox <--> PluginBox <--> Bearerbox
>
>
>
> For those who want to still make use of SQLBox.
>
>
>
> My initial design is to use an asynchronous callback chain to allow slow
> plugins to not hold up the processing of faster messages. This would be
> especially useful in the co

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 <rene.klu...@chimit.nl>
CC: kannel_dev_mailinglist <devel@kannel.org>
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 <rene.klu...@chimit.nl 
<mailto:rene.klu...@chimit.nl> > 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>  
[mailto:donaldjs...@gmail.com <mailto:donaldjs...@gmail.com> ] Namens Donald 
Jackson
Verzonden: donderdag 6 oktober 2016 11:26
Aan: Rene Kluwen <rene.klu...@chimit.nl <mailto:rene.klu...@chimit.nl> >
CC: kannel_dev_mailinglist <devel@kannel.org <mailto:devel@kannel.org> >
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 <rene.klu...@chimit.nl 
<mailto:rene.klu...@chimit.nl> > wrote:

Yeah, I think it’s useful.

Mainly to prevent having a chain of many boxes if you want some extra 
functionality.

In fact, just now I was thinking of making such a box. So you saved me some 
work.

 

Tip: Maybe you can make it source-code compatible with the smppbox server 
plugin architecture.

 

== Rene

 

 

Van: devel [mailto:devel-boun...@kannel.org <mailto:devel-boun...@kannel.org> ] 
Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 9:25
Aan: kannel_dev_mailinglist <devel@kannel.org <mailto:devel@kannel.org> >
Onderwerp: [RFC] New 'box' Kannel Pluginbox

 

Hi everyone,

 

I have started laying the foundations for a new 'box' for Kannel which intends 
to allow users more flexibility in terms of the platform.

 

At the moment there are many ways to get messages into the bearerbox, namely: 
smsbox, wapbox, opensmppbox, smppbox, ksmppd, sqlbox. Some rely on routing in 
their own process and others allow bearerbox to do the routing. What they all 
have in common is they don't allow external or third party applications help 
make decisions at processing time (with the exception of ksmppd/smppbox). 

 

My new planned box is called pluginbox which will basically be like SQLBox - 
but instead of using database callbacks, it will allow linking of dynamic 
libraries (.so|.dylib) which will allow custom 
interception/filtering/modification of message packages to and from various 
boxes.

 

So a hypothetical scenario for this box could be something like

 

SMSBox, SMPPBox/KSMPPD, WapBox <--> PluginBox <--> Bearerbox

 

Or even

 

SMSBox, SMPPBox/KSMPPD, WapBox <--> SQLBox <--> PluginBox <--> Bearerbox

 

For those who want to still make use of SQLBox.

 

My initial design is to use an asynchronous callback chain to allow slow 
plugins to not hold up the processing of faster messages. This would be 
especially useful in the context of people using HTTP and other external 
services to process routing decisions. The plugin would also be able to return 
a status to 'reject' a message packet which would in turn not submit to the 
target receiver.

 

My plan is also to implement at least one example plugin (probably an HTTP 
plugin?) which can show the submission and manipulation of a message packet in 
both directions.

 

So here I am looking for comments.

 

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

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

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

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

 

Here is the initial version : https://github.com/donald-jackson/kannel-pluginbox

 

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

 

Regard

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



-- 
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 <rene.klu...@chimit.nl>
CC: kannel_dev_mailinglist <devel@kannel.org>
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 <rene.klu...@chimit.nl 
<mailto:rene.klu...@chimit.nl> > wrote:

Yeah, I think it’s useful.

Mainly to prevent having a chain of many boxes if you want some extra 
functionality.

In fact, just now I was thinking of making such a box. So you saved me some 
work.

 

Tip: Maybe you can make it source-code compatible with the smppbox server 
plugin architecture.

 

== Rene

 

 

Van: devel [mailto:devel-boun...@kannel.org <mailto:devel-boun...@kannel.org> ] 
Namens Donald Jackson
Verzonden: donderdag 6 oktober 2016 9:25
Aan: kannel_dev_mailinglist <devel@kannel.org <mailto:devel@kannel.org> >
Onderwerp: [RFC] New 'box' Kannel Pluginbox

 

Hi everyone,

 

I have started laying the foundations for a new 'box' for Kannel which intends 
to allow users more flexibility in terms of the platform.

 

At the moment there are many ways to get messages into the bearerbox, namely: 
smsbox, wapbox, opensmppbox, smppbox, ksmppd, sqlbox. Some rely on routing in 
their own process and others allow bearerbox to do the routing. What they all 
have in common is they don't allow external or third party applications help 
make decisions at processing time (with the exception of ksmppd/smppbox). 

 

My new planned box is called pluginbox which will basically be like SQLBox - 
but instead of using database callbacks, it will allow linking of dynamic 
libraries (.so|.dylib) which will allow custom 
interception/filtering/modification of message packages to and from various 
boxes.

 

So a hypothetical scenario for this box could be something like

 

SMSBox, SMPPBox/KSMPPD, WapBox <--> PluginBox <--> Bearerbox

 

Or even

 

SMSBox, SMPPBox/KSMPPD, WapBox <--> SQLBox <--> PluginBox <--> Bearerbox

 

For those who want to still make use of SQLBox.

 

My initial design is to use an asynchronous callback chain to allow slow 
plugins to not hold up the processing of faster messages. This would be 
especially useful in the context of people using HTTP and other external 
services to process routing decisions. The plugin would also be able to return 
a status to 'reject' a message packet which would in turn not submit to the 
target receiver.

 

My plan is also to implement at least one example plugin (probably an HTTP 
plugin?) which can show the submission and manipulation of a message packet in 
both directions.

 

So here I am looking for comments.

 

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

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

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

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

 

Here is the initial version : https://github.com/donald-jackson/kannel-pluginbox

 

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

 

Regards,

-- 

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





 

-- 

Donald Jackson
 <http://www.ddj.co.za/> 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 <rene.klu...@chimit.nl> wrote:

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



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

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 <devel@kannel.org>
Onderwerp: [RFC] New 'box' Kannel Pluginbox

 

Hi everyone,

 

I have started laying the foundations for a new 'box' for Kannel which intends 
to allow users more flexibility in terms of the platform.

 

At the moment there are many ways to get messages into the bearerbox, namely: 
smsbox, wapbox, opensmppbox, smppbox, ksmppd, sqlbox. Some rely on routing in 
their own process and others allow bearerbox to do the routing. What they all 
have in common is they don't allow external or third party applications help 
make decisions at processing time (with the exception of ksmppd/smppbox). 

 

My new planned box is called pluginbox which will basically be like SQLBox - 
but instead of using database callbacks, it will allow linking of dynamic 
libraries (.so|.dylib) which will allow custom 
interception/filtering/modification of message packages to and from various 
boxes.

 

So a hypothetical scenario for this box could be something like

 

SMSBox, SMPPBox/KSMPPD, WapBox <--> PluginBox <--> Bearerbox

 

Or even

 

SMSBox, SMPPBox/KSMPPD, WapBox <--> SQLBox <--> PluginBox <--> Bearerbox

 

For those who want to still make use of SQLBox.

 

My initial design is to use an asynchronous callback chain to allow slow 
plugins to not hold up the processing of faster messages. This would be 
especially useful in the context of people using HTTP and other external 
services to process routing decisions. The plugin would also be able to return 
a status to 'reject' a message packet which would in turn not submit to the 
target receiver.

 

My plan is also to implement at least one example plugin (probably an HTTP 
plugin?) which can show the submission and manipulation of a message packet in 
both directions.

 

So here I am looking for comments.

 

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

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

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

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

 

Here is the initial version : https://github.com/donald-jackson/kannel-pluginbox

 

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

 

Regards,

-- 

Donald Jackson
 <http://www.ddj.co.za/> 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