qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject C++ Plugin modules
Date Thu, 27 Jun 2013 05:46:36 GMT
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)

        (I'm not actually sure of the distinction between these
        but they are both required for persistence)

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

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.



To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message