I agree with Rob and others about QMF being it's own project with independent release cycles/website etc. We could probably start as a sub project of Qpid and depending on how it goes make a proposal to move it to a top level project.
Rajith On Wed, Jan 4, 2012 at 1:51 PM, Rob Godfrey <[email protected]> wrote: > On 4 January 2012 18:55, Ted Ross <[email protected]> wrote: > > > Users and Devs, > > > > I'd like to make a proposal and start a discussion about the future of > QMF > > and Qpid broker management. > > > > QMF (Qpid Management Framework) started out as a way to remotely manage > > the Qpid C++ broker using AMQP messaging. There was an agent embedded in > > the broker and a console API written in Python. It was then expanded for > > more general purpose use when an agent library and API were developed so > > developers could provide QMF manageability to their software components. > > > > There has been quite a bit of evolution including new APIs and even a new > > protocol based on map/list-encoded messages. One of the important > changes > > that occurred with the new protocol (called qmf2) was that QMF became > > purely layered over AMQP messaging. The original protocol required the > > participation of the broker to assign addresses, to track agents, and to > > cache schema information (didn't scale well, didn't work in multi-broker > > environments, had multiple protocol issues, wreaked havoc with > clustering). > > > > The QMF code is embedded in the "qpid" namespace because older versions > > were tightly coupled to the broker code. Now that the coupling has been > > reduced (consisting of the public messaging API), it is possible to move > > QMF out of the "qpid" namespace and allow it to be a separate component, > > with its own build and release artifacts. > > > > I would like to propose that we: > > > > 1. move the C++ implementation of qmf2 out of the qpid tree and into > > the "extras" subdirectory (where the Python implementation is), > > 2. move the swig bindings (Python, Ruby, etc.) into extras as well, and > > 3. deprecate the old qmf components. > > > > The old components are in: > > > > * cpp/{include,src}/console > > * cpp/{include,src}/agent > > * cpp/{include,src}/qmf/engine > > * cpp/bindings/qmf > > > > > +1 I think this will be beneficial both for QMF and Qpid Core development. > > Should we be thinking of spinning QMF off as a separate project in its own > right? I'm guessing that if the coupling is loose enough there is no need > to tie release schedules of QMF to the release cycles of the rest of the > project? > > > The last part of the proposal is to remove the dependency that the qpid > > tools (qpid-config, qpid-stat, qpid-route, etc.) have on the Python QMF > > library. If you haven't noticed, these tools run fairly slowly, > especially > > when grouped in large numbers in a script file. This is because QMF > > (version 1) has a significant amount of handshake that occurs on > connection > > setup. Since the tools don't need agent-discovery or > schema-introspection, > > they can operate much more simply by sending and receiving properly > > formatted messages to and from the broker agent. I prototyped this with > > qpid-stat and found it to be visually instantaneous in its response time. > > It also reduced the number of queues and bindings related to the > > management session to one. > > > > > Can you confirm that you are going to be testing this with the Java Broker > as well as the C++? > > Happy to help if there are any issues that crop up on the Java side of > this. > > > > Fraser Adams has contributed a Java implementation of the new QMF > > protocol. It makes sense to me that this should be included with the C++ > > and wrapped components that I propose moving into "extras". > > > > > Agreed. > > Cheers, > Rob > > Thoughts? > > > > Regards, > > > > -Ted > > > > >
