+1 - totally agree with this proposal.
----- Original Message -----
> 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
>
> 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.
>
> 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".
>
> Thoughts?
>
> Regards,
>
> -Ted
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
