You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Andrew Stitcher <as...@redhat.com> on 2013/06/27 07:46:36 UTC
C++ Plugin modules
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)
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?
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: C++ Plugin modules
Posted by Andrew Stitcher <as...@redhat.com>.
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: C++ Plugin modules
Posted by Gordon Sim <gs...@redhat.com>.
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.
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.
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).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: C++ Plugin modules
Posted by Alan Conway <ac...@redhat.com>.
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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: C++ Plugin modules
Posted by Gordon Sim <gs...@redhat.com>.
On 06/28/2013 07:46 PM, Andrew Stitcher wrote:
> On Fri, 2013-06-28 at 17:03 +0100, Gordon Sim wrote:
>> The Protocol/ProtocolRegistry and the ObjectFactory (two different
>> things) introduced a way of extending the existing monolithic broker.
>> I'm not sure its entirely fair to say there are two different approaches.
>>
>
> I didn't make myself clear enough - when you introduced these
> abstractions you still left the old non-abstracted code - so we now have
> to understand both the old way and the new way.
Your point was clear enough, I just don't agree with you.
The difference between the 0-10 and 1.0 protocols and implementations is
far, far bigger than the minor differences resulting from the fact that
the 0-10 code does not implement the Protocol abstraction. (At present
that abstraction is for _additional_ protocols, since in part it still
assumes the existence of 0-10).
By being a plugin, some valuable abstractions were forced onto the
development of 1.0. Had the Protocol abstraction not been introduced, I
believe the overall 'cognitive burden' would be greater, not less.
As I said, I think it would be useful to make the 0-10 support optional.
However if the burden of fixing _all_ the problems on the past is always
added to the burden of developing a new feature we would never move
forward. The fact that 0-10 was so ingrained throughout the codebase
meant that a piecemeal approach was the only way anything would happen.
That in turn means that some way of limiting the scope of changes has to
be found, even if that falls short of the ideal picture.
(Of course, a balance always needs to be struck and striving for the
best that can be achieved is always important. I just don't accept that
means that an imperfect step forward is worse than no step at all).
>> The existing 0-10 support could - in my view, should - eventually be
>> made optional. We need _more_ modularity.
>
> Precisely, however just introducing a new abstraction actually makes
> things worse in the short term though because there are now more
> concepts to understand.
Again, I disagree. By introducing a new abstraction the door is opened
to reuse that abstraction for other use cases. It also more clearly
shows the way forward for the future, even if not all the code is
aligned in that direction yet. Yes, there is a new concept to
understand, but that does not in itself mean things a worse. (The
previous absence of any clear concept could be seen as a problem, now
fixed).
I believe in evolutionary steps towards something better _and_ more
complete, rather than waiting until it can all be done in one step (an
approach which in my experience tends never to deliver). Progress is
progress even if there remains a long way to go.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: C++ Plugin modules
Posted by Andrew Stitcher <as...@redhat.com>.
On Fri, 2013-06-28 at 17:03 +0100, Gordon Sim wrote:
> ...
> > 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.
>
> The Protocol/ProtocolRegistry and the ObjectFactory (two different
> things) introduced a way of extending the existing monolithic broker.
> I'm not sure its entirely fair to say there are two different approaches.
>
I didn't make myself clear enough - when you introduced these
abstractions you still left the old non-abstracted code - so we now have
to understand both the old way and the new way.
> The existing 0-10 support could - in my view, should - eventually be
> made optional. We need _more_ modularity.
Precisely, however just introducing a new abstraction actually makes
things worse in the short term though because there are now more
concepts to understand.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: C++ Plugin modules
Posted by Gordon Sim <gs...@redhat.com>.
On 06/28/2013 03:34 PM, Andrew Stitcher wrote:
> I think my point is that although it forces some decoupling, it doesn't
> force enough decoupling to make effective plugin modules.
The decoupling it does force is useful however, even if not sufficient.
[...]
> 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.
The Protocol/ProtocolRegistry and the ObjectFactory (two different
things) introduced a way of extending the existing monolithic broker.
I'm not sure its entirely fair to say there are two different approaches.
The existing 0-10 support could - in my view, should - eventually be
made optional. We need _more_ modularity.
The fact that we already have large blocks of monolithic code shouldn't
hold us back from trying to ensure that new functionality doesn't simply
magnify the problem. In practice, plugins have provided significant
impetus for improvement in this regard.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: C++ Plugin modules
Posted by Andrew Stitcher <as...@redhat.com>.
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 <gs...@redhat.com> 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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: C++ Plugin modules
Posted by Jakub Scholz <ja...@scholz.cz>.
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 <gs...@redhat.com> 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: users-unsubscribe@qpid.apache.**org<us...@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: C++ Plugin modules
Posted by Gordon Sim <gs...@redhat.com>.
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: C++ Plugin modules
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 27/06/13 06:46, Andrew Stitcher wrote:
> 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?
Hmmm. So I'm going to have to take a completely diametrically opposite
position here (sorry Andrew!) and assert that to the contrary we should
actually look to maximise the modularity and (potentially) increase the
use of plugins. I say "potentially" for the latter because I *generally*
share Gordon's thoughts "I'm not overly concerned whether a module is
compiled in to qpidd itself or compiled as a separately loaded library"
however the latter approach does somewhat force the issue of decoupling,
which IMHO isn't a bad thing to do.
My reasoning for feeling diametrically opposite is that qpid really does
seem to be evolving, to some extent proton has acted as a catalyst here,
but there are other reasons too. One non-technical reason relates to
"product positioning" - I've banged on about this a number of times
before, but as someone whose "day-job" role includes having to make
business cases around product choices it's *really hard* to come up with
compelling arguments as to why Qpid C++, Qpid Java, ActiveMQ etc. etc.
and related to that there are "commercial sponsorship" aspects around
products (some of you I'm sure will know what I'm alluding to - Gordon
certainly will) and there may be different emphases made on support for
different AMQP products.
All of that IMHO points to the very strong need to make the various Qpid
products compelling and to maximise opportunities for reuse elsewhere if
necessary (proton is a good example here and is I believe - ironically -
being used in ActiveMQ but not -yet- in Qpid Java).
That sort of modularisation in the C++ suite I think helps play to its
strong suits, ultimately the reason I chose Qpid C++ broker was its raw
performance, but I have some quirky use cases - for example real time
producers caused me to really like circular queues - a feature not
supported in the Java broker (to quote Rob it's give some of their
customers apoplexy) and of course Qpid C++ is nice and fast!
Being able to get the C++ broker absolutely "lean'n'mean" stripped back
with racing suspension and nitrous injection would be awesome for me. I
look at things like ZMQ and think that there could be some advantages
but equally I think a modular approach in qpidd gives the opportunity to
have ones cake and eat it.
I guess there are other things too, so I believe (though I'm no expert)
that AMQP 1.0 places less emphasis on the need for a broker and allows
more peer to peer communication between Nodes via Links (is that
correct?) but I'd still assume that in practice an awful lot of the
building blocks are still necessary and useful. At the very least
there's a need to configure, but I'd assert a very definite need to be
able to manage and monitor what might amount to the "client runtime" too.
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.
The management and monitoring side of things is a *really good* example
of this. QMF is currently quite intertwined which is less than ideal,
especially given the discussions on the subject of looking towards AMQP
1.0 support. You might be aware of the fact that I recently added QMF2
support to the Java Broker in the form of a plugin. I mainly did this
initially as a bit of fun to see if I could, but I think that it's been
most valuable as a catalyst for focussing attention on divergence
between the QPid products and the need for some cohesion in management
and monitoring. I guess that one key thing I took from that was that it
only really took me a couple of weekends to get some reasonable QMF
support in place despite having absolutely zero background in the Java
Broker code base and despite the fact that the plugin API was a moving
target at the time.
This has really convinced me that improved modularisation in general and
specifically moving the QMF stuff into something properly pluggable and
decoupled is the absolute only way to stand a chance of migrating
towards AMQP 1.0 Management without completely trashing support for
existing QMF tooling. Hopefully you'll all have read the various threads
that kicked of when Ken Giusti made a change to the asynchronous python
QMF API relating to QMF2 support. That's a tiny shard of the likely
carnage that might be caused moving to AMQP 1.0 Management unless we're
very careful.
Remember I said in a previous reply about me going off on one on things
I cared about :-D
Just my 2p and all that, but hopefully it's some food for thought?
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: C++ Plugin modules
Posted by Alan Conway <ac...@redhat.com>.
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org