Happy New Year all...

So, at the start of this new year I think it is important that we try to
focus on improving the experience of our project... and in particular I
think we should be looking at making the project look like a single coherent
whole.

Currently the Java and C++ Brokers look and behave almost completely
differently, and I think we all should be trying hard to remedy that
situation.

The first step in my grand plan to fix this was obviously implementing AMQP
0-10

The next task I set myself was to investigate how we can use a single set of
management and configuration tools across the two brokers such that the user
experience is common.

To that end I have spent the last couple of weeks implementing a prototype
QMF management layer in the Java Broker, attempting to use the same
management schema as used by the C++ broker.  Further I have implemented the
required methods to enable federation between Java and C++ (and to use the
same tools to set it up) - both static and dynamic routing has been
implemented.

Once trunk is unfrozen I will be able to apply my patch that provides for
qpid-tool, qpid-route et. al to work against the Java Broker.

In implementing QMF Management and Federation I have come up against a
number of obstacles caused by assumptions built in to the QMF management
schema that are based on the behaviour of the C++ broker (e.g. that it
doesn't support multiple vhosts),  I also have a number of
questions/comments on the schema as a whole.  I've collected all these on
the following wiki page:

http://cwiki.apache.org/confluence/display/qpid/Broker+Management+QMF+Coverage

I would be grateful if those familiar with the C++ broker and it's
management could answer some of the questions therein... Further I would
like to get feedback on my comments and suggestions for additions to the
management capabilities.  From those more familiar with the Java management
capabilities - a review to point out any other capabilities that cannot be
carried out through QMF would be very helpful.

In terms of next steps in uniting the user experience:

1) I think we need to collectively agree on how we can update the management
schema to work fully with the Java Broker and hopefully to expand its
coverage to that it encompasses everything that can currently be performed
by the Java JMX management solution.

2) I will be trying to put together a wiki page of all the "extensions" to
AMQP that the brokers currently implement (e.g. arguments to queue/exchange
declare, bind,subscribe, etc...).  ultimately we should try to unify these
as well - and also to define a mechanism so that clients can detect on
connection which extensions are available.

Beyond the configuration and management work I've started already, the
biggest gap is probably ACLs - and I've not looked at all at that yet.

Overall I think with a bit of work from both the C++ and Java communities we
can get the brokers to look and behave much more similarly... however we
will also need to change the way we work a bit so that when we decide to add
new features we attempt to discuss and agree before implementing. It will do
no good to get the brokers temporarily aligned if they immediately begin to
drift apart again.

Your thoughts?

-- Rob

Reply via email to