[rabbitmq-discuss] C++ client options

[Daniel Pocock]

On 08/08/13 00:57, Alan Antonuk wrote:
>
> On Wed, Aug 7, 2013 at 1:49 PM, Daniel Pocock <daniel at pocock.com.au
> <mailto:daniel at pocock.com.au>> wrote:
>
>     Does this mean we need to block and/or use threads to receive
>     messages?
>
>
> Yes, the state of rabbitmq-c and SimpleAmqpClient when waiting for a
> delivery from a consumer is you need to block, optionally with a timeout.
>  
> The problem I'm stating is that AMQP has some async parts to the
> protocol, and rabbitmq-c doesn't do anything to handle these events as
> they're fired from the broker.  They're only 'seen' by rabbitmq-c when
> synchronous calls are made.
>
>
>     Do you envisage making it work like boost::asio or have you seen
>     anything like that for AMQP?
>
>
> A few years back I started to implement a pure C++ AMQP client library
> leveraging boost::asio.  You can find it here:
> https://github.com/alanxz/libamqp-cpp
> The project was not completed. I don't have plans to resume work it.
>
> Recently I have been doing a bit of design work to see what would be
> necessary to create an library that leverages libuv to make a
> fully-functional native AMQP client.

Personally, I wouldn't want to favour any of these solutions over any
other, they are all good.

The most important thing will be demonstrating how it integrates with
higher level code, particularly if the high level code is using an event
loop other than the one you choose yourself.  E.g. will the end user
have to run your event loop in a thread and when they get callbacks from
your code, they will have to pass data to their own event loop thread in
a thread-safe manner?

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.


>  
>
>     Did you collaborate with anybody for the Debian package of the C
>     client?
>     http://packages.debian.org/jessie/librabbitmq-dev
>
> That package is very old.  People have come to me time-to-time for
> assistance in creating a Ubuntu and/or Debian package, and not having
> a lot of knowledge in the process I do what I can to help out.
>  Currently there is some packaging material in the debian directory of
> the rabbitmq-c repo.  It is somewhat out of date, though not as old as
> what you've linked.
>

I'll contact the maintainers and if they are not actively updating it, I
might volunteer to refresh it


> I personally would like to move the packaging details out of the
> repository to allow for different distributions to come up with their
> own independent packaging, as each distribution seems to do things in
> a slightly different and incompatible way. If you or someone you know
> is willing to step up and help maintain said package, I will do what I
> can to help out.
>

Debian often maintains packaging artifacts in git repositories in alioth
these days.  When we import your release tarball into our git
repository, we can easily tell it to ignore any debian/ directory you
have.  For older versions of Debian this was problematic though.  My own
suggestion is that you can include your own debian/ artifacts in your
repository if you wish to maintain them, but when you prepare a release
tarball, exclude that subtree.

>
>     Has anybody discussed a package of the C++ client?
>
>
> I haven't heard of anyone doing so.  One roadblock is that when
> SimpleAmqpClient was created it used a newer version of boost than
> came packaged with the LTS version of Ubuntu because it needed the
> boost.chrono library which was fairly new at the time.  I'm not sure
> if the situation has changed since then.
>

I would be aiming to introduce something in Debian unstable to begin
with.  From there, it will propagate to other distributions over time
and if those distributions operate commercially (like Ubuntu) and their
clients really want it, they will hopefully collaborate with you to
resolve the problem and contribute fixes for you.

> Again if you or someone you know is willing to step up and help
> maintain an SimpleAmqpClient package, I will do what I can to help out.
>

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?



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130808/d04996c6/attachment.htm>