qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: C++ Plugin modules
Date Fri, 28 Jun 2013 10:23:37 GMT
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 

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?

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

View raw message