<div dir="ltr">On Thu, Aug 8, 2013 at 1:46 AM, Daniel Pocock <span dir="ltr">&lt;<a href="mailto:daniel@pocock.com.au" target="_blank">daniel@pocock.com.au</a>&gt;</span> wrote:<div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    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?<br></div></blockquote><div><br></div><div>Noted.�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">

    <br>
    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&#39;ve come across so far is OpenMAMA:<br>
    <a href="http://www.openmama.org" target="_blank">http://www.openmama.org</a> - 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.</div></blockquote><div><br></div><div>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&#39;re doing.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im"><br></div><div class="im">
    <br></div>
    I&#39;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?<br>
    <br>
    <br></div></blockquote><div>I don&#39;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.</div>
</div><br></div></div>