Just a few thoughts: Since it appears to be the only asynchronous python QMF client, my own project needs the qmf.console package to continue to work.
I presume that those tools, which Ken mentions as being based on QMFv2 now, do not use this package. Now that (the patched version of) it is actually capable of getting QMFv2 updates, I'm happy to use that (and have been). I am concerned, however, that some of its internals (e.g.; fetching a schema) might depend on QMFv1. They certainly worked before the patch that enabled v2, so they must have been using v1. Thus my question is whether, if QMFv1 suddenly went away, these internal operations would seamlessly switch to using v2, or would they just break? What I'd like to see is for someone who knows what they are doing* to patch qmf/console.py (probably in that same _TryToConnect() method) so that it does not establish any v1 connections at all, confirm that they think that it still works, and pass me a copy to test in my project. If all that goes well, or if the library used by all the tools grows asynchronous capability (and I learn to use it), then, and only then, would I be comfortable with the disappearance of any QMFv1 capabilities. [* That is, not me. As has been pointed out here recently, it uses the man behind the curtain sections of the Qpid python library, not the giiant face on the screen "messaging" interface.] I don't know whether anyone besides me (and the QMF python tutorial I started with) uses qmf/console.py . I haven't noticed anyone speaking up during our discussions, so I may be the only one affected. But there could well be users not reading the list. While they may not have been promised compatibility across dot releases, it seems a shame to break their code unless there are real savings to be had. The v1 code exists. Unless other changes require it to be maintained, or unless it represents a significant performance drag, why go to the effort of removing it, at least before AMPQ 1.0? Bill On Mon, May 6, 2013 at 8:54 AM, Ken Giusti <kgiu...@redhat.com> wrote: > Folks, > > My overall concern is that this project doesn't have the bandwidth to > adequately support two different management implementations. That's really > the crux of the issue for me. > > The current problems we've been dealing with come down to the fact that > there's inadequate test coverage for dual use QMFv1 and QMFv2. The latest > problem (QMFv2 updates from the broker being dropped by qmf.console) has > been broken for a long time. We shipped this broken for several releases. > Why? Inadequate test coverage. > > Most - if not all - of the python tests use QMFv1. Yet qpid-tools are now > (mostly) based on QMFv2. I'm not even sure to what extent the QMF agent > libraries are tested - perhaps not at all for the cmake builds. This > results in partial test coverage of both implementations - neither > implementation gets fully tested. > > In the end, we try to support both, but are not able to guarantee the > level of quality our users deserve for either. > > We should be concentrating our efforts on one implementation, and making > it the best we can. > > -K > > ----- Original Message ----- > > From: "Gordon Sim" <g...@redhat.com> > > To: users@qpid.apache.org > > Cc: d...@qpid.apache.org > > Sent: Monday, May 6, 2013 7:11:18 AM > > Subject: Plans for QMF v1 and v2 (was Re: QMFv2 object update bug [WAS > Re: Questions from a novice]) > > > > On 05/03/2013 04:51 PM, Ken Giusti wrote: > > > I want to know what the > > > QPID project's plan is for QMFv1/v2 support in the C++ broker going > > > forward. > > > > > > If the consensus is that a 1.x C++ broker is going to support both > > > QMFv1 and QMFv2, then simply reverting all the changes I've made to > > > qmf.console and reverting to the old behavior is probably the least > > > risky move. > > > > > > On the other hand, if the consensus is to deprecate QMFv1 support > > > prior to releasing a 1.0 C++ broker - or perhaps toss in the towel on > > > QMFv2 - then the final fix for this needs to take that plan into > > > account. > > > > > > So I'm going to call a discussion among the developers, proposing we > > > vote on what QMF support a 1.x C++ broker will provide. > > > > I'd like to move the discussion to the user list as there are folks > > there who may not be on dev list but would be impacted or might > > otherwise have an opinion. I'm assuming everyone on the dev list is also > > on the user list (if not you really should be :-) > > > > By way of a short introduction, Ken's question comes after a long thread > > focused on some issues around the dual support of v1 and v2 of the QMF > > protocol in the console.py python library for applications built to > > manage/monitor the c++ broker. > > > > > Once that's decided, we can determine the most appropriate fix. > > > > > > As an aside - we've talked a lot about preserving behavior and > > > functionality across 0.X releases in this thread. While nobody wants > > > to gratuitously break stuff, this project has reserved the right to > > > remove and change functionality between 0.x releases in order to fix > > > bugs and provide new features. Things may be different once we get > > > to 1.x, but for 0.x, this has been the case. > > > > 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. > > > > 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. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > > -- > -K > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
