qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Date Thu, 21 Mar 2013 18:16:47 GMT
On 21/03/13 13:19, Ken Giusti wrote:
>    I'd rather see a single "top level" broker configuration command that supports all
the configuration aspects of the broker.  Openssl and NSS (certutil) take this approach. 
 I think it would tend towards unifying the configuration experience (e.g. naming of common
options would be consistent, need for familiarity with only one command, etc).
Ooohhh now you're talking!! So I'll take it a stage further I'd like 
*very much* to see a unified approach that aligns configuration not just 
limited to "all the configuration aspects of the broker" but unified 
configuration and monitoring across the C++ and Java brokers (and 
beyond, wouldn't it be just grand to set a good precedent for unified 
AMQP management?).

I've made a bit of a start on this grand crazy vision, you might have 
seen my post at the weekend announcing a QmfManagementPlugin for the 
Java Broker. It might not be the "right" approach I'm taking, but hey 
I've got qpid-config and the QMF GUI both working with both brokers, 
which seems like a pretty decent start. The main limiting factor isn't 
so much "the control protocol" be it QMF/JMX/REST/whatever there remain 
some differences in the underlying management models which ought to be 
addressed - it's very frustrating when even for arguments with the same 
of very similar purposes the option name may be different between the 
brokers. Never mind just config aspects I'd quite like an AddressString 
that I had working on a client talking to the C++ broker to behave the 
same way when I talk to the Java broker.

I'm probably already sounding like a broken record on this topic, is it 
just me or do others share this crazy vision? If not is there a really 
compelling reason for the brokers behaving so differently?


To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message