management, what should the future look like? (was Re: Location for Java QMF2 code + QMF GUI)

[Gordon Sim <gs...@redhat.com>]

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.

> 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.

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

Re: management, what should the future look like? (was Re: Location for Java QMF2 code + QMF GUI)

[Rob Godfrey <ro...@gmail.com>]

On 25 March 2013 20:52, Gordon Sim <gs...@redhat.com> 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: dev-unsubscribe@qpid.apache.**org<de...@qpid.apache.org>
> For additional commands, e-mail: dev-help@qpid.apache.org
>
>