[rabbitmq-discuss] C++ client options

Daniel Pocock daniel at pocock.com.au
Thu Aug 8 20:14:47 BST 2013

On 08/08/13 20:05, Alan Antonuk wrote:

>> Another thing that comes to mind is the question of adding an abstraction
>> layer, just like JMS in the Java world.  The only one I've come across so
>> far is OpenMAMA:
>> http://www.openmama.org - do you believe RabbitMQ users could benefit
>> from coding to the OpenMAMA API and using some low-level driver for AMQP or
>> RabbitMQ specifically?  This would be more like the JMS programming
>> paradigm.
> I believe something like this would be something layered on top of the
> protocol library, and not necessarily baked into the library itself. As to
> whether you should go this direction, I would imagine it depends on the
> requirements for whatever you're doing.

I agree - the Avis MQ solution appears to work like that:

- C++ Application code
- OpenMAMA C++ API
- OpenMAMA itself
- Avis "bridge" code (part of OpenMAMA repository)
- Avis C client layer

So to phrase my comments another way: instead of re-inventing or
extending the C++ API that exists now, maybe the work involved in making
such a bridge module delivers more benefit for the C++ user and/or is
easier to achieve

Here are some demos that show how a C++ user codes to the OpenMAMA API:



and here are the bridges for Qpid and Avis:


>> I'd like to understand your feelings about the future of the API before
>> committing to that - do you see something based on libuv happening in the
>> near future, e.g. within 6 months?
>> I don't plan on making any drastic API changes to SimpleAmqpClient, its
> purpose in my eyes is to give an easy interface to using rabbitmq-c from
> C++, so it will continue to develop SimpleAmqpClient to support the various
> bits of functionality that rabbitmq-c supports.  A libuv-based library will
> likely be developed under a different library name, whether or not the
> functionality gets rolled back into an existing library is TBD.  Will this
> happen in 6 months? I have no idea - it depends on how much free time I
> have to work on these kinds of projects.

Ok, that's fine - I didn't want to put any urgency on it, just to get a
feeling for the future direction of each component

More information about the rabbitmq-discuss mailing list