Jonathan Robie wrote:
On the whole, I really like this. Comparing the example programs to the
existing examples, I think it does simplify quite a bit.
A few thoughts:
1. Streaming data into or out of messages
I really want to be able to stream into or out of messages directly.
Instead of:
message_data << "Message " << i;
message.setData(message_data.str());
I would like to be able to do something like:
message.getData() << "Message " << i;
Yes, I can see that would be convenient.
2. Having a Subscription object is really very helpful.
3. These examples don't create queeus and bindings explicitly - is that
intentional? I assume the existing APIs continue to exist for this, but
that is not going to bridget API versions.
Right. Binding is protocol specific and consequently is not represented
directly in this API. Some uses are covered in the implementation behind
the scenes, e.g. topic subscriptions that bind a subscription queue to
the exchange representing the topic. Other uses are really best thought
of as configuration and could be accomplished as part of deployment
using configuration tools/scripts.
4. I notice you do not use keyword arguments. Is the move away from them
intentional? Why?
So far I haven't felt the need for them. They were very useful in the
generated signatures reflecting the 0-10 commands where there were often
lots of fields and where specific uses of those commands only needed
different specific subsets of the parameters.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
