[rabbitmq-discuss] C++ client options

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:

http://git.openmama.org/?p=OpenMAMA.git;a=blob;f=mama/c_cpp/src/examples/cpp/mamapublishercpp.cpp;hb=HEAD

http://git.openmama.org/?p=OpenMAMA.git;a=blob;f=mama/c_cpp/src/examples/cpp/mamasubscribercpp.cpp;hb=HEAD

and here are the bridges for Qpid and Avis:

http://git.openmama.org/?p=openmama-qpid.git;a=tree;f=mama/c_cpp/src/c/bridge;h=f4747d48a008bae21891b78d5cfeb5fd8f47713c;hb=HEAD

>>
>>
>> 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