Ah, I didn't realize the messaging API was for the 1-0r0 spec, I thought it was for 0-10. Thanks for clearing that up, and everything else as well!
That said, I for one would be very happy if you could just implement a qpid::messaging API for the 0-10 spec, or give me some way with the qpid::client API to deal with the connection, queues, and receivers procedurally (hopefully supporting a getMessage-like timeout) without having to extend a MessageListener class and without having to deal with SubscriptionManager. If there's a way to do that today, please let me know and document it somewhere. I gave up trying to figure it out after trolling the source. P.S. I am very happy to continue running an 0-10 broker for the long-term forseeable future while the AMQP working group finalizes 1-0 and while vendors break it in. Please don't rush to implement 1-0r0 on my account. :p PPS. I'm kind of curious, are you grafting the 1-0r0 API on top of an 0-10 implementation, or is the C++ broker now implementing both versions? On Apr 26, 2011, at 3:39 PM, Chris Sears wrote: > On Tue, Apr 26, 2011 at 5:33 PM, David Hawthorne <[email protected]> wrote: > >> I found it confusing and difficult to use the new messaging API is because >> it has new terminology for existing concepts (e.g. node, link, subject, >> x-declare, x-bindings) that I already understood, as well as the difficulty >> I had in trying to figure out exactly what the node and link concepts >> represented. The fact that they represent different concepts (based on >> inferences from your explanation) is only more confusing. At first glance >> the messaging API looks really sweet and easy to use, but after digging into >> it, it's actually harder to figure out and use than the old client API. >> This goes all the way down to the fact that I skipped over the x-declare >> and x-bindings bits of the documentation because of the "x-" in their names; >> I thought they referred to special xml magic. >> >> > I would agree that the messaging API is not easy to use, especially for > those who have experience with the old client API. That said, the > introduction of new terminology (node, link) is due to changes in the AMQP > spec, not the Qpid folks just making up new terms for the fun of it. Many of > the concepts in the old client API were based on the 0-8 (or prior) spec. In > the 1-0r0 spec ( > http://www.amqp.org/confluence/display/AMQP/AMQP+Specification), it seems > like they tried to simplify things by removing exchanges and changing the > binding key / routing key logic. As I understand it, the goal of the > messaging API was to bridge the old spec and the new spec, which is not > trivial given their differences. > > The "x-" prefix is called out in the spec as a standard way name > vendor-specific options and avoid field name collisions. Other protocols use > this same convention for headers. > > - Chris --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
