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. >> > > Well put! This was the point I was trying to make. > > As a trivial example, it was because the xml exchange was in a separate > library that the exchange registry was modified to allow registration of > different types of exchange rather than adding to the if/else clause in > declare (where for example the management exchanges have been added, > unnecessarily increasing coupling). > > This is not to say that the better design *requires* dynamically loaded > modules, but as Fraser says, on occasion it 'forces the hand' in the right > direction. > > Another example would be the 1.0 stuff I've been working on. I had to > introduce the ObjectFactory into the broker to allow different types of > object to be created via the generic management create/delete function. Had > the 1.0 work not been in separate plugins it would have been easier to > simply add some extra clauses to Broker::createObject() and > Broker::deleteObject(). > > A counter example is the federation code which is much more tightly > coupled to various points in the broker codebase. Had that been envisaged > as a plugin I think some different design decisions would have been forced. > > I will stress again that the real issue is about compile- and runtime- > optionality and lower coupling, not dynamically loaded libraries per se. > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
