Alan Conway wrote:
I propose thinking in terms of qpid-send/qpid-recv which are basically
command line versions of the API used to send/recv message content
generated outside the utility (that content could come by file,
command-line args, stdin, etc), and then qpid-source/qpid-sink which are
used as artificial sources/sinks for messages and more oriented towards
testing/diagnostics/performance.
I'm not sure I see the benefit of this distinction. I would be inclined
to think of qpid-send/receive as tools that send messages generated in
various ways: 2 of which being read from stdin and generated internally,
we could add more as needed.
I think the main benefit is keeping qpid-send/qpid-recv as simple
utilities targeted primarily at our users. I would expect testing and
benchmark scenarios are going to have an increasing number of complex
options around generating different kinds of load, different sizes of
messages, randomized content, etc. All those options are going to be a
bit daunting to read through for someone who just wants to send and recv
messages from the command line.
Also, as the testing/benchmarking utilities wouldn't actually be used to
build applications, I think there is a bit more freedom to change them,
whereas send/recv utilities IMHO need to be treated as another form of
the client API since they might well be an important part of a real
application.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
