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: [email protected]
For additional commands, e-mail: [email protected]
