[rabbitmq-discuss] AMQP library APIs

Thu Aug 8 19:09:11 BST 2013

Excellent points.

Having had a chance to sleep on it - its seems to me you need to have an
API that exposes the protocol at some level. A layer that abstracts away
the concept of channels can always be layered over the top of that.

On Thu, Aug 8, 2013 at 6:58 AM, Michael Klishin <mklishin at gopivotal.com>wrote:

> Alan Antonuk:
>
> > That makes me wonder what is it that developers use channels for?  My
> understanding is they're were designed to be an 'error scope' at a protocol
> level. I don't see a lot of developers using them that way, and sometimes
> its the source of a bit of pain (having to recreate any resources that get
> destroyed as a result of a channel exception, or in bad cases, their whole
> app aborts because the channel dies).
>
> For separating things that may require different error handling.
>
> > My thinking is that an API could be created that internally uses
> channels intelligently to give more native feel to error handling. One
> example of changing the API might be: instead of apply basic.qos to a
> channel, you apply it to a consumer, and internally the library maps a
> consumer to a channel, so a BasicQos on a consumer.  The same can be done
> for other aspects of the protocol (this is what I ended up doing with
> SimpleAmqpClient).  A downside being the API may not map 1:1  to a lot of
> the documentation that is out there.
>
> Nearly every other client exposes basic.qos on a channel, not a consumer.
> Not doing the same
> will likely only cause more confusion at this point, not less.
> --
> MK
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130808/66addd7c/attachment.htm>