So, the initial thinking for AMQP Management has (finally) now been uploaded so that anyone can see it [1]. As Fraser mentioned, the scope of the AMQP Management work at OASIS is currently purely about "mechanism" and not defining specific operations / attributes that are available on a managed object.
-- Rob [1] https://lists.oasis-open.org/archives/amqp/201305/msg00005.html On 7 May 2013 20:18, Fraser Adams <[email protected]> wrote: > 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].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
