On 06/27/2013 01:46 AM, Andrew Stitcher wrote:
We have a small number of plugin modules in the Qpid C++ code base (in the Unix port):They are: amqp.so (Broker AMQP 1.0 plugin) amqpc.so (Client AMQP 1.0 plugin) xml.so (XML exchange plugin) rdma.so (Broker RDMA plugin) rdmaconnector.so (Client RDMA plugin) store.so legacystore.so (I'm not actually sure of the distinction between these but they are both required for persistence)
Also ha.so, the High Availability plugin. It doesn't have any build-time external dependencies (it has a run-time dependency on CMAN or some other cluster resource manager)
The amqp/amqpc plugins depend on qpid-proton. However I'd suggest that supporting the newest version of the protocol where you can is likely a core part of the qpid functionality and making it a plugin where the 0-10 protocol version isn't doesn't make too much sense. So I think we should stop building it as a plugin. Currently not loading the plugin is the only way to turn the protocol off if it is not wanted on the broker side so we will need a way to turn the protocol off. Obviously if the build can't find qpid-proton it can't build 1.0 support. And this will add a proton dependency to any qpid artifact compiled like this, but that isn't a real problem I think. The xml plugin has some heavyweight dependencies (Xqilla and Xerces) so it does make sense to leave this as a plugin so you don't need the dependencies unless you need the XML exchange. However I wonder how widely used is this plugin? Is there anyone out there using xml exchanges? As far as I can tell this code has hardly been touched in years. The rdma support plugins also have reasonably heavyweight dependencies and so also makes sense to be a module as you only want the dependencies if you are using rdma. I can say with fair certainty that this code is lightly maintained and I for one would be happy to see it go. Are you using it? Do you have a friend using it? The store plugins are the only ones that make some sense to me as plugins (although I don't understand their dual plugin nature on Linux). We do actually have 2 implementations of these plugins - Linux and Windows and I can conceive that we could have multiple store plugin types, However like all our current plugins we have no real API or ABI (or more correctly SPI/SBI) and this makes it very hard to develop a plugin with a different release lifecycle from qpid. I've gone on a bit long here, but essentially 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?
I have no strong objection to linking some of the existing modules (e.g. ha) directly into the broker, but I don't see any benefit to doing so. I do want them to at least remain separate libraries so we have a clear separation of "extended" features from the broker core.
Cheers, Alan. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
