Hi Bernd, pls see my comments inline. On Thu, Sep 29, 2011 at 9:18 AM, Bernd Fondermann <bernd.fonderm...@googlemail.com> wrote: > On Wed, Sep 28, 2011 at 17:22, Eduardo Martins <emmart...@gmail.com> wrote: >> Comments? It's a very modest starting point, since the module event >> listeners interfaces and event firing code are the major tasks, but >> what do you people think about it? > > I briefly reviewed the patch. Unfortunately, I'm currently approaching > multiple deadlines in real life, so my time is limited. > > Within the short time I had to review the patch I'd didn't get the > full idea behind this. > > So if you could give me a head-start, what would be a typical use case > for these event listeners?
There are lots of XMPP Servers out there, covering the XMPP core functionality, and with more or less extensions. You can say some have good performance, some are open source, some are Java code, etc. IMHO, what sets apart Vysper is its ability to be easily integrated in other systems, such as jee app servers, where out of ordinary service logic can be added. Advertising is an example of such logic, XMPP users could receive messages with ads, just as mobile phones today get these through SMS. Now imagine how this can be done with Vysper today, you would need to extend/hack each Module, and that is not really useful. The typical solution for this kind of needs is an event delivery framework, something that allows registration of listener code, that reacts to events received. In concrete, we want Vysper (modules) to publish certain events, so we can have apps that enrich the standard XMPP server logic, and these apps are represented by the event listeners. In my patch I only propose the foundations to connect listeners in Vysper Modules. Each Module should now decide what events makes sense to publish, and thus generate its own event and listener interfaces. I could have opted for having the listeners at XMPPServer level, a concrete event interface, and an event listener interface with something like processEvent(Event), but this ends up in a mess of listener code, trying to decrypt what kind of events it gets. It also makes much more difficult for Modules to make the decision on whether an event is really needed, that is, if a Module has no listeners, why should it bother with making events, a deployment may not be interested on handling events from certain modules... > Additionally, I'm asking myself the following questions: > + Which modules would need to be adopted? Do we require modules to > implement this? Ok, this is where the fun starts, I added an empty impl of the method to add a listener to a module, this means it works as it is now. Anyway I guess the base method impl should construct a common facility that manages the set of listeners, and that facility should then be exposed to Modules, I did not want to go deeper before understanding if the whole idea is accepted by the Vysper team and community. To proceed with this, Module developers shall specify its own event framework, which in concrete are the events and listener interfaces. We can start by targeting a specific Module, kind of "pilot program". > + Would JMX be a better means of interacting with modules? JMX events are mostly useful for "remote" interactions, we could later add listeners that expose events to JMX too, if there is interest on that... > + How are events emmitted? Synch, Async? How do we prevent event > consumers from stopping the world when doing their thing? I guess async is better, listeners should not be able to introduce any overhead to the core XMPP Server function... A draft of a possible distribution implementation would be a common facility which efficiently distributes events using a shared thread pool or alike, and some hash function to pick up the delivering thread, routing related events in serialized fashion. I will be on vacation next week, but I will be checking mail frequently. -- Eduardo .............................................. http://emmartins.blogspot.com http://redhat.com/solutions/telco
