This is exactly what I've been looking for. Timing is excellent.

I am glad you like it. This was inspired by one of the user's comments: http://www.tigase.org/content/presence-forwarding-tigase-users-presence-website#comment-4577

However, even though this is high on the TODO list, it is planed for next version, so it won't be available soon.

The idea for this has changed. Now we are going to make every Tigase component a simple PubSub component, similarly to scripting support it will be a basic component API available to all components.

Using this API, an internal component plugins or elements will be able to register as PubSub nodes for this component. This will allow for a wide applications, such as server-level events notification to any given destination, possibly clustering support can be based on this as well.

i really like how this idea developed. i'm currently operating a MUC-based backend which i want to migrate to one based on PubSub. my motivation: MUC rooms live on a single node in the cluster, whereas pubsub nodes can be persisted and therefore easily distributed to several nodes in a cluster.

my original idea circled around implementing this on top of redis -- redis offers excellent ways to replicate data, and it will only be better with the upcoming 2.8 release. i'm not a big fan of investing time and effort in replicating SQL databases. i understand tigase comes a long way, but maybe it's time to provide additional support for these kinds of backends? just a thought...

back to this ticket: i'd love to see support in that new API which easily allows me to register my own nodes from my components.

This will be implemented as part of the new component framework.

I think this is what you call evenBus now. Please update the ticket with some progress and pointers.

We (WE ALL!) have to define some interesting ;-) events in Tigase Server and start to publishing it.

We have to make tests of dEventBus in real environment, to find and remove bottlenecks.

Still TODO:

support for standalone components.

Bartosz Malkowski wrote:

We (WE ALL!) have to define some interesting ;-) events in Tigase Server and start to publishing it.

Indeed, I have plenty of ideas (clustering could/should be based on this), publishing SM events like: new user registered, user logged in, changes online status, etc.... Tigase monitor events - detected high CPU, high memory usage, some feature malfunction, etc....

We have to make tests of dEventBus in real environment, to find and remove bottlenecks.

Indeed. I would start with Tigase Monitor. It is the least critical and practically non-existed. So there is no rewriting code, we just have to write planned functionality and use event-bus. I do not expect a high load here so impact would be low.

Also I would really like to add support for it in the SM, ideally each plugin should be able to publish events. This would put a significant load on eventbus so it would be a good performance verification.

However, publishing is relatively easy, subscribing and consuming notifications is more interesting. But this would be the clustering code - both publishing and subscribing - ultimate test for performance and reliability.

Still TODO:

support for standalone components.

Well one more TODO:

We need documentation for evenbus so we know how to use it.

Bartosz, please update the due date. If the due date is beyond the end of Jan 2015, move this task for next version.

Bartosz, what is the status of the task? Is it implemented and available for 7.1 version?

Works fine. Implemented everything planned except for support, except for support for external components.

Add documentation page about this new stuff and close the ticket.

I'll combine your document with mine %bmalkow should be uploaded when new documentation package tonight.

OK %daniel

Fix and improve my documents, please :-)