On 01/04/2012 05:55 PM, Ted Ross wrote:
I'd like to make a proposal and start a discussion about the future of
QMF and Qpid broker management.
[...]
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),
Under extras/qmf there is the 'old' console API and something called
qmf2-prototype. Just for clarity, what is the status of that second module?
2. move the swig bindings (Python, Ruby, etc.) into extras as well, and
3. deprecate the old qmf components.
When would you envisage being able to drop them entirely?
The old components are in:
* cpp/{include,src}/console
* cpp/{include,src}/agent
Again just for clarity, the old code is in
cpp/{include,src}/*qpid*/console and cpp/{include,src}/*qpid*/agent,
right? Is the qmfv2 implementation that is to be moved the code in
cpp/{include,src}/qmf/ apart from the engine subdirectory?
* cpp/{include,src}/qmf/engine
* cpp/bindings/qmf
What about the qmf-gen utility? Would that move also? Or is that now
something specific to the C++ broker?
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.
So you're proposing these would be self-contained utilities, with no
dependencies on any QMF libraries? (Or are you proposing they be
migrated to 'new' QMF libraries?)
The tools - and indeed the broker schema - have evolved in a rather
ad-hoc manner. While I find them useful, there are some limitations and
some areas where this ad-hoc evolution shows through. I'd like to see a
more holistic and comprehensive and forward looking review at some point.
[...]
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".
We have previously discussed introducing a 'sandbox' or 'nursery' area
to which new components would initially be added until we have proven -
as a community - that we can support them. I think this would be a good
candidate for such a scheme (to avoid repeating the experience with the
Java implementation of QMFv1 that was contributed).
In general, I would welcome moving the agent and console APIs and their
implementations out of the qpid tree.
I would also like to see broker management get more attention in its own
right. I feel that focus has sometimes been sacrificed to the more
general goals of QMF.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
