Re: Performance measurement clients using the new API.

[Rafael Schloming <ra...@redhat.com>]

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:dev-subscribe@qpid.apache.org