I also think that if any moves are being done, I would go further than just bumping them into the extras directory. That still isnt all that visible or seperate from Qpid in itself, I think the core QMF components would collectively warrant at least sub project status with their own release timelines and website etc.
Robbie On 4 January 2012 18:51, 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 >> >> --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
