qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: QMF and Broker Management
Date Thu, 05 Jan 2012 22:11:53 GMT
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:users-subscribe@qpid.apache.org


Mime
View raw message