[rabbitmq-discuss] Erlang client: Future of lib_amqp

[Ben Hood]

Scott,

On Tue, Aug 4, 2009 at 3:23 PM, Scott
Brooks<scott.brooks at epicadvertising.com> wrote:
> The main feature I saw when using lib_amqp was a constant interface that
> divorced the rest of the apps from the rabbitmq server.  That way I didn't
> need to include the rabbit hrl's into the rest of my app, I just used the
> interface exposed by lib_amqp.

On the subject on being able to include header files in a more
convenient way, I have to agree. Since R12B-5 you can load code from
archives, unfortunately the same doesn't apply for header files.

However, I don't think avoiding the need to set the include path in a
make file is sufficient justification to wrap records with functions.

lib_amqp has the tendency to cover over the expressiveness of Erlang's
record and pattern matching syntax. This is even more apparent with a
command structured protocol like AMQP.

> I've attached a rough patch that expands on it a bit to be able to adjust
> the defaults when defining a queue, and exchange.

Thanks for the patch, I've seen what you've tried to achieve, but it
would be inconsistent of me to accept it and still stand behind what I
said above :-) Because the codegen now generates sensible defaults, I
think the plain jane Erlang syntax is most concise way to override
defaults. For example, the default exchange type is the direct
exchange, so declaring a direct exchange looks like this in the lower
API:

amqp_channel:call(Pid, #'exchange.declare'{exchange = <<"foo">>})

If you need this exchange to be a topic exchange, it would look like:

amqp_channel:call(Pid, #'exchange.declare'{exchange = <<"foo">>, type
= <<"topic">>})

lib_amqp shortened this to:

lib_amqp:declare_exchange(Pid, <<"foo">>, <<"topic">>)

Which is not that much shorter. Furthermore, this is the shortest
variant - as soon as you want to set other flags on the
exchange.declare command, the arity of the necessary overloads grows
considerably which in turn reduces clarity. Basic.Publish is probably
the best example of this.

Also, when reading somebody else's code, it is immediately apparent
what each variable means.

A counterexample in lib_amqp is bind_queue. Who remenbers off by heart
what order the parameters (routing key, exchange and queue) are
supposed to be passed in?

Anyway, thanks again for the patch, please don't get discouraged by
the judgement of this particular matter, so keep them coming because
we are interested in popular usage patterns.

HTH,

Ben