On Fri, Nov 8, 2013 at 12:21 PM, Andrew Stitcher <astitc...@redhat.com> wrote: >> For what it's worth (and I wouldn't say it's worth much), I'd prefer >> renaming the C++ ones as well. I think it does a better job of >> telling the user what they're using, one of several variants of >> qpid-send or -receive. > > I think there is a difference of mindset then. I view > qpid-send/qpid-receive as generally useful utilities, that perhaps > should be installed by default when we install qpid-clients. > > For simple enough cases they allow you to send/receive messages from the > command line with no further tooling. And for this purpose on of the > variants needs to be the default installed - I'd suggest the native code > versions might be best suited. So keeping them called just > qpid-send/receive works best for this. I'd certainly not object to > installing links to them as part of the tests called > qpid-cpp-send/receive. > > I think of the current set of "test" executables they are the only ons > that qualify to be generally useful.
Yes, I do think they're primarily for testing. Not narrow testing, but rather the kinds of one-off testing that end users might do when troubleshooting. Since the client may have as much part as the server in such troubleshooting, the language involved is still important, according to this view, and should be visible. I'm all for a default. If we had a qpid-send facade, I'd see no problem with defaulting the impl lang to C++. I just think it's slightly better to avoid obscuring the language: going with qpid-send, qpid-java-send, and qpid-python-send leaves the user to guess what that first one is. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
