On 06/05/13 12:11, Gordon Sim wrote:
For my part, I am in favour of removing QMFv1 support, if necessary
providing some sort of adapter or plugin to deal with any use cases
for which this might prove problematic. I think QMFv2 is now firmly
established as the current management mechanism for the c++ broker.
My take on this is that I'm more than happy to see the back of QMF1 but
I'd be keen to understand whether or not this results in *breaking changes*.
A couple of things I mentioned on the dev group around this point are
a) The asynchronous python API - that's where this discussion started
the problem is that the callbacks that have actually worked to date work
for QMF1, there was a suggestion of an additional objectUpdate() call
for QMF2 which is OK as it wouldn't break existing clients as long as
QMF1 data was still pushed, but would if it was disabled. Forcing
clients to change from statUpdate() and propUpdate() to objectUpdate()
(and any changes regression testing that this involves) is clearly a
breaking change. Parochially I've only got one tool that uses the async
API but I'd prefer it not to be broken (mainly because I wrote it at
home for a work use and I'm not responsible for supporting it and I'd
end up having to explain the subtleties we're discussing here to someone
with a lot less QMF experience than me :'( ). At a push as long as I
have decent notice I can rewrite it myself, but others may not have that
luxury - as Bill has mentioned previously he's a contractor so when he
finishes up his contract and someone else takes over his work they won't
have this background and it might "silently" stop working properly.
b) If anyone has been writing Agents using QMF1 then clearly they are
likely to break. Parochially this doesn't affect me, but I'm not sure
quite how we can gauge how much it may affect others.
Perhaps rather like the automake to cmake change we start off by giving
gentle nudges then get a bit more forceful, so disabling the QMF1 broker
updates as Ken has suggested might be a start (along with some decent
documentation and a deprecation notice in the qpidd -h text).
I'd personally quite like to see the python async API shim the QMF2
update to make it behave like statUpdate()/propUpdate() though I accept
this might be difficult and would have to bow to people who know more
about the implementation of this than me.
Ultimately I also think we should be starting to think about an AMQP
1.0 based management standard and how we would transition to that.
That is however a larger question that shouldn't hold up the immediate
decision regarding QMFv1 though it may inform it a little.
Yeah I totally agree, I hope that it's not too long before Rob is able
to share the draft AMQP 1.0 Management Spec. It'd be good to have a
"lively discussion" about this among a wider group. Rob and I had a
couple of decent chats over Easter but I'm keen to start some proper
thinking on how we can make this a reality. Unfortunately I suspect that
the QMF1/QMF2 quirks are likely to be minor compared to moving to AMQP
1.0 Management, but hopefully not insurmountable, I'm hopeful that it
should be possible to shim between ManagementAgent and ManagementNode
and vice versa which should help with migration. As we've discussed a
pluggable Management layer for the C++ broker would be good, it really
helped in the Java broker - I was able to get QMF2 support up and
working in a couple of weekends with no prior knowledge of the Java
broker code base.
<rant>
As an aside the AMQP 1.0 Management specification is only covering the
protocol as I understand it, but I'd be quite keen for us to get our act
together with respect to APIs. Yes I know it's possible to write QMF2
using the protocol directly, but frankly it's not as interoperable as it
might be (C++ binary strings versus UTF8 strings are a personal
"favourite" of mine resulting in byte[] or String respectively in Java -
ClassCastException hell :-)). So I think it's useful to have a decent
API, however the four or five APIs that we seem to have for QMF is less
helpful :-D - can we agree on one when we start looking at AMQP 1.0
Management?
</rant> :-)
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
