On 01/13/2011 05:14 PM, [email protected] wrote:
On Thu, 13 Jan 2011, Andrew Kennedy wrote:
I would suggest a nice pluggable architecture. There would be a broker
info provider class, just like you suggested, which would be feeding
into a one or many publisheres. These could be, for example:
* A '/var/lib/qpid/' filesystem driver on Linux
* A 'C:\Documents and Settings\Qpid User\Local Settings\Application
Data\' filesystem driver for Windows
* A Registry driver on Windows
* An Active Directory driver on Windows Server
* an SNMP MIB generator for systems with an SNMP agent
* A JMX driver on the Java broker
* A QMF driver for both Java and C++ brokers
You could include a lot of information in the provider's dump and the
publisher plugins will decide what information to filter out of this
and select and how (and how often) to present it.
I think this is a different proposal to Mick's.
Yours is about adding indirection for the broker's internal mgmt event
system, so you could for instance get a bunch of log output for mgmt
events, or you could get them published as qmf events.
To my impression, Mick's is much smaller. It's about a simple way to
discover some basic info (and I'd argue it's strictly runtime
configuration).
I think there are really a couple of different areas discussed in this
thread. I think Mick's original use case is really about OS integration,
and there is an element of discovery to it in that one of the things you
want to be able to do is discover what brokers are running on your
system and figure out how to talk to them.
I think Discovery (with a capital D), is really different in scope since
that is about figuring out what brokers are out there on the whole
network. That's not to say they couldn't share mechanism, but the use
case is definitely quite different.
Management (QMF, JMX, SNMP) comes to mind when thinking of extracting
config information from a broker, but there's obviously a bootstrapping
problem since those mechanisms are only useful when you already know the
broker you want to speak to, and as Andrew points out that leads to the
notion of some sort of scheme for publishing the same config information
in multiple ways.
Personally I'd pick an area (e.g. OS integration, network discovery,
etc) and focus on building out the use cases there a bit to get a more
complete picture.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
