2
votes

At first I thought QPID documentation is great, but now I find it confusing. I'm using the C++ API of QPID-0.6 with the qpid::messaging namespace (I saw I have access to low-level AMQP with qpid::client, but it is not what I wish now).

With AMQP, I would declare an exchange with a type, declare a queue and a binding before sending a message. With QPID, I can give a single Address to the Sender to send to. Is there any documentation with address examples, which does the same? (create various exchange, queue, and create binding).

Notably, I found an Address syntax online, which included node,link,x-declare and x-binding fields. However digging the 0.6 code this wasn't found, and instead a more simplistic syntax is seen (with fields named node-properties and x-properties), and its documentation is not too straightforward, also lacking any examples.

In examples/messaging/client.cpp, this is the most I found: #response-q; {create:always, type:queue, node-properties:{ x-properties:{auto-delete:true}}}

  • Is setting up various types of exchange, queue and binding still possible with this simpler address syntax?

  • Or moving to something post-0.6 would be preferrable? (if it is stable enough, and have a less nasty syntax)

  • Or my approach is wrong, and I should not want to pre-create and bind receiver queues for my exchanges with the high-level API?

Thank you.

1

1 Answers

2
votes

The messaging API in 0.6 was an early preview only. It has evolved a little since then, particularly wrt the addressing syntax. The syntax you quote above is based on the trunk implementation (now stable), which will be released at the end of Oct.

I would not advise using the messaging API with the 0.6 libs; either use trunk or wait until the next release (which is going to be called 0.8 - 0.7 being the trunk code inbetween releases).

The in-progress guide to the messaging API is available at http://qpid.apache.org/books/0.7/Programming-In-Apache-Qpid/html/. The section on addressing is worth reading through. Feedback on that document (and indeed all other aspects of the project) is always welcome at [email protected]!