On 25 March 2013 20:52, Gordon Sim <[email protected]> wrote: > On 03/25/2013 06:32 PM, Fraser Adams wrote: > >> If there's strength of feeling that extras is more appropriate then >> that's fine and I'll be OK with that, but then the location of the ruby >> stuff seems inconsistent (I'm not knocking the ruby stuff, just trying >> to figure the most consistent place). >> > > I think you make a good case there and I certainly have no objections to > it going under tools. > > I think this is definitely tools rather than extras... Intuitively I feel that tools is part of our supported release and extras is not (it is more of a sandbox area). What Fraser has been working on seem to be like something we wish to support as a released artefact.
> The "stand alone project" thing is interesting, there was talk of this >> for QMF last year but it didn't sprout wings, and I guess probably >> won't. Perhaps it might be time for a proper concerted think about >> "management" in general. Rob looks like he might announce some stuff >> from OASIS on AMQP management in the near future, so perhaps the time is >> ripe to move all the management stuff into a new space to start the ball >> rolling on that general trajectory? >> > > I think it very much is a good time to start thinking about management in > general. I'm not sure I would begin by moving the existing stuff around > though. > > I think I would begin by discussing what we all individually and > collectively want from management. > > Indeed. Obviously I am going to start by stating that I believe that Qpid should be aiming to support (and become the de facto reference implementation of) the AMQP 1.0 Management specification. One outcome here would be for the tool that Fraser has contributed to become the basis for a generic management tool that could work across all compliant implementations of AMQP 1.0 Management. This can be separated into (at least) two parts: mechanism and model. Currently the AMQP group has been focused on the mechanism - how to give "create", "read", "update", and "delete" instructions... not on the types of objects to be managed and the properties of those objects. I think there is a very strong case that this second part, the model, should be community driven based on the use cases of providers and consumers of messaging solutions. I would very much like the Qpid community to be an active part of this. Cheers, Rob > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
