On Thu, 2011-01-13 at 17:14 -0500, [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). > > Justin
i agree with justin. this is grander than my little info-writer. cool idea, though! --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
