On Fri, 2013-06-28 at 14:15 +0200, Jakub Scholz wrote: > My impression right now is that while the broker has some sort of modular > design, the interfaces are not really advertised / published (correct me if > I'm wrong). So maybe the discussion can be taken a step further and focus > on whether it is intended to have the plugin interfaces published, > advertised and stable enough to support development of custom plugins. I > can very easily imagine some custom exchanges, stores or even management / > monitoring plugins. > > In my opinion, that would help to grow the community a lot. Right now - > especially on the C++ broker side - it often seems to me that while the > "community" is always willing to answer questions and help with problems, > the development is to a large extent closed to very few people. > > Regards > Jakub > > > On Fri, Jun 28, 2013 at 1:33 PM, Gordon Sim <[email protected]> wrote: > > > On 06/28/2013 11:23 AM, Fraser Adams wrote: > > > >> Another good argument for modularisation is that it forces the hand in > >> terms of better decoupling. In the recent discussions on removing chunks > >> of code from the code base it's pretty clear that some things > >> "organically evolved" and have ended up creating some quite monolithic > >> artefacts. > >>
I think my point is that although it forces some decoupling, it doesn't force enough decoupling to make effective plugin modules. I totally agree with Gordon and Fraser that having plugins is a good way to modularise a code base and that was my entire point when I advocated for it 4/5 years ago. And the various registries allow a more dependency injection approach to the broker code which is a good thing for many reasons - they are a good design approach even without plugins. It has just turned out more like Jakub's experience that the plugin interfaces aren't well designed or stable. In practice our current plugin "interface"s are ad hoc, and force coupling from the plugin to some of the internal libraries of qpid, which makes it hard in the current scheme to reorganise the libraries. For instance I'd been thinking that there was little point in producing libqpidbroker which is only used by a single shipped executable. However the plugins actually link against this library to provide various things and so that makes it impossible to simply get rid of the library. What we should have done is to define a plugin interface (probably as a abstract class) providing all the things that a plugin can use and pass it into the plugin when it is initialised rather than allowing them to link against literally anything in qpid. This would actually have allowed for some standalone plugin testing too. And even when we introduce the registries it is hard work to go back and fit them to the previous code. Viz the old Amqp 0-10 support does not use the new protocol object factory. So that we've ended up with both approaches to understand and maintain. So in summary, I agree with nearly everything you've all written! It's about designing internal broker functionality as if it was it's own plugin, and it's about designing plugins as if they were their own little sealed world with everything passed to them (from the qpid POV) Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
