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?
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
