> Yes, I think this would give us a more flexible product that can be > used in a variety of places. I don't think it would require much work. > > - Change our startup to start the felix container. > - Give the core broker an activator to kick start its loading as we have now. > - Change PluginManager to simply be a helper lookup class. > > I'd be intereseted to know what the other devs think about the > approach, would be good to foster a community of plugins that can > augment the broker's functionality. > > Martin
So, personally I think the problem highlighted by Danushka is one that we should look to solve - by using Felix in the way that we are currently doing, we are preventing the broker being run inside his application. My main concern is obviously that we preserve compatibility from a user experience perspective with the existing broker packaging. As to the ability to develop new plugins, my main concerns are that we are not yet at the point where our internal interfaces are stable - thus any "plugins" developed would essentially be at the developer's own risk. Ideally before advertising that people should be developing plugins we would settle on defined APIs which such plugins could use. Thoughts? Rob --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
