On Wed, 31 Mar 2010, Rafael Schloming wrote:
Overall I'm not sure we should try to cram too much into qpid-send and
qpid-recv. I think it might make sense to have two sets of utilities with the
difference being based on whether the utilities themselves generate the
messages, or whether they're simply used to send/recv messages generated
outside the utilities. I think the use cases around these two scenarios are
fairly different.
The things that generate/consume their own content are more oriented towards
diagnostics/testing/benchmarking, and I would expect to have options around
frequency, size, type of content, etc, whereas the things that send/recv
existing content would have more options around reading in messages from
various formats, writing them out, etc.
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.
(Watch out! Naming talk.)
Generally speaking, names in user-facing tools should identity match their
equivalents in other contexts (the API modulo stemming, language in
documentation, etc). Variation is useful to the user when it stands for a
difference, and it's detrimental when it doesn't.
Since "recv" doesn't appear in the API or elsewhere in qpid messaging, it
shouldn't appear in the tool's name either. "recv" may seem nice because
it's shorter, but it's one more variant for the user to remember.
So, I'd vote for qpid-receive instead.
Justin
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
