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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
