location of qpidt, qpid-ctrl etc.

[Fraser Adams <fr...@blueyonder.co.uk>]

Hi all (especially Gordon)
I was just freshening up my system as a result of uplifting to 0.25 
doing a bunch of rebuilds etc. and a few things about the python tools 
installed from /tools/src/py have just struck me.

1) qpid-send/qpid-receive have been added relatively recently to the 
src/py directory here but they aren't included as part of the setup.py 
install - is this accidental or deliberate?

2) There's been a fair bit of reference to qpidt in the mailing list 
(and qpid-ctrl can be useful too on occasion) but they seem to be 
sitting in /cpp/src/tests which is probably not the first place people 
are likely to visit to look for control utilities. Would it make sense 
to move them to tools?

Cheers,
Frase

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

Re: location of qpidt, qpid-ctrl etc.

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

On 07/22/2013 06:47 PM, Fraser Adams wrote:
> I guess one slight issue is that it might take a bit of time to "have a
> bit more feedback etc" on things living in /test because it's probably
> not the first place most users would look and it's not normally
> "installed" by default so I expect qpidt is only likely to either be
> "stumbled upon" or possibly found via people noticing it mentioned in
> discussion threads and then grepped.

Yes, that's a very fair point and I think its probably worth revisiting 
the discussion around management tooling in general.

> I'd tend to agree with the sentiment about having a generic
> create/delete/list capability though I guess the more generic the more
> the syntax to control it needs a good manual (we've already had a
> discussion on relative merits of qpidt vice qpid-ctrl, the latter of
> which I believe could do the same as qpidt, but is ironically probably
> *too* generic :-))

Yes, qpid-ctrl can invoke add/delete, but also any other method and at 
present at least it is therefore a little less intuitive for the simpler 
stuff. Neither qpid-ctrl nor qpidt are fully polished end-user tools at 
this point. However I do feel loathe to simply add more stuff to 
qpid-config without an attempt at some 'genericising'.

> Out of curiosity would you be interested if I were to put this sort of
> behaviour into the GUI?

Very!

> There's probably useful scope for having a
> fairly generic key/value entry page to cater for some of the more
> "edge-case" queue options, and certainly it might make supporting the
> currently quite wildly varying queue options between the C++ and Java
> broker a more tractable problem to solve. Once the stuff is in place to
> support general key/value queue options it ought to be pretty easy to do
> the sort of general thing that qpidt allows.

Very much agree.

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

Re: location of qpidt, qpid-ctrl etc.

[Fraser Adams <fr...@blueyonder.co.uk>]

Thanks Gordon,
I guess one slight issue is that it might take a bit of time to "have a 
bit more feedback etc" on things living in /test because it's probably 
not the first place most users would look and it's not normally 
"installed" by default so I expect qpidt is only likely to either be 
"stumbled upon" or possibly found via people noticing it mentioned in 
discussion threads and then grepped.

I'd tend to agree with the sentiment about having a generic 
create/delete/list capability though I guess the more generic the more 
the syntax to control it needs a good manual (we've already had a 
discussion on relative merits of qpidt vice qpid-ctrl, the latter of 
which I believe could do the same as qpidt, but is ironically probably 
*too* generic :-))

Out of curiosity would you be interested if I were to put this sort of 
behaviour into the GUI? There's probably useful scope for having a 
fairly generic key/value entry page to cater for some of the more 
"edge-case" queue options, and certainly it might make supporting the 
currently quite wildly varying queue options between the C++ and Java 
broker a more tractable problem to solve. Once the stuff is in place to 
support general key/value queue options it ought to be pretty easy to do 
the sort of general thing that qpidt allows.

Regards,
Frase


On 22/07/13 14:53, Gordon Sim wrote:
> On 07/20/2013 11:21 AM, Fraser Adams wrote:
>> Hi all (especially Gordon)
>> I was just freshening up my system as a result of uplifting to 0.25
>> doing a bunch of rebuilds etc. and a few things about the python tools
>> installed from /tools/src/py have just struck me.
>>
>> 1) qpid-send/qpid-receive have been added relatively recently to the
>> src/py directory here but they aren't included as part of the setup.py
>> install - is this accidental or deliberate?
>
> Accidental, I believe.
>
>> 2) There's been a fair bit of reference to qpidt in the mailing list
>> (and qpid-ctrl can be useful too on occasion) but they seem to be
>> sitting in /cpp/src/tests which is probably not the first place people
>> are likely to visit to look for control utilities. Would it make sense
>> to move them to tools?
>
> We had a short thread about this in the not so distant past. The 
> problem is a proliferation of tools on one hand, but a feeling (at 
> least from me!) that simply adding more and more things to qpid-config 
> is not the right way forward either.
>
> The 'decision' was to punt the decision down the road a bit by putting 
> qpidt in alongside the tests until we have a bit more feedback etc to 
> go on.
>
> Having a generic create/delete/list capability (by which I mean one 
> that you don't need to explicit alter or augment just to support a new 
> object type) is in my view hugely useful.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


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

Re: location of qpidt, qpid-ctrl etc.

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

On 07/20/2013 11:21 AM, Fraser Adams wrote:
> Hi all (especially Gordon)
> I was just freshening up my system as a result of uplifting to 0.25
> doing a bunch of rebuilds etc. and a few things about the python tools
> installed from /tools/src/py have just struck me.
>
> 1) qpid-send/qpid-receive have been added relatively recently to the
> src/py directory here but they aren't included as part of the setup.py
> install - is this accidental or deliberate?

Accidental, I believe.

> 2) There's been a fair bit of reference to qpidt in the mailing list
> (and qpid-ctrl can be useful too on occasion) but they seem to be
> sitting in /cpp/src/tests which is probably not the first place people
> are likely to visit to look for control utilities. Would it make sense
> to move them to tools?

We had a short thread about this in the not so distant past. The problem 
is a proliferation of tools on one hand, but a feeling (at least from 
me!) that simply adding more and more things to qpid-config is not the 
right way forward either.

The 'decision' was to punt the decision down the road a bit by putting 
qpidt in alongside the tests until we have a bit more feedback etc to go 
on.

Having a generic create/delete/list capability (by which I mean one that 
you don't need to explicit alter or augment just to support a new object 
type) is in my view hugely useful.


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