Hi all, I'm back to work, any other feedback on this? -- Eduardo .............................................. http://emmartins.blogspot.com http://redhat.com/solutions/telco
On Sun, Oct 2, 2011 at 12:24 PM, Eduardo Martins <emmart...@gmail.com> wrote: > 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 >
