On Thu, 2013-06-27 at 14:11 +0100, Gordon Sim wrote: > On 06/27/2013 06:46 AM, Andrew Stitcher wrote: > > I think that we should minimise our use of modules and try to remove > > those we already have - either stop building them as plugins or > > remove them altogether. > > > > Thoughts? > > Personally I'm not overly concerned whether a module is compiled in to > qpidd itself or compiled as a separately loaded library. > > What _is_ important is having optional functionality - optional both at > build time and at runtime.
100% agree with this. > > It's also important to keep improving the modularity of the code, > regardless of how things are compiled. The use of plugins is certainly > not a panacea in that regard, but it has forced some extra work to keep > things decoupled which has been valuable. I certainly not suggesting that removing modules should allow us to make worse code design choices. However I feel that when you have plugins you have to make much better (and somewhat different) design choices and that really we haven't been terribly successful in that regard. One specific issue is that many (most?/all?) of our plugin modules depend on the the internals of either the broker or client and not upon a specifically exported plugin interface - this causes dependency issues. > > Specifically regarding the xml exchange, I think keeping that as a > module makes sense as you say. I certainly wouldn't want to remove it > without a more compelling reason to do so. The code does get tested, it > has been used (though much less commonly than any of the standard > exchanges) and it doesn't pose much of a maintenance burden. > > (You also missed the ha module from your list). Oops, good catch - the ha module is one that I would really consider rolling into the main broker code. It has no extra dependencies and I think you could argue that it's functionality is not especially niche or advanced. Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
