[rabbitmq-discuss] Fwd: Erlang client: Future of lib_amqp

[Ben Hood]

---------- Forwarded message ----------
From: Scott Brooks <scott.brooks at epicadvertising.com>
Date: Wed, Aug 5, 2009 at 2:09 PM
Subject: Re: [rabbitmq-discuss] Erlang client: Future of lib_amqp
To: Ben Hood <0x6e6562 at gmail.com>


Yeah, there are valid reasons on either side.  It would be nice to
have an interface to program against so if the records changed, it
wouldn't really matter.

Either way once the first real release is out there, there should be a
relatively stable interface.

I've got some patches for the rabbitmq-c library that I'll clean up
and send along.

Thanks
Scott


On 4-Aug-09, at 6:28 PM, Ben Hood wrote:

> 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

---------------------
Scott Brooks
Web Developer
Epic Advertising - New York, Toronto, San Francisco, London
www.EpicAdvertising.com
60 Columbia Way, Suite 310
Markham, ON L3R 0C9
(905) 946-0300 x2356 - phone
(888) 666-3120 - fax
scott.brooks at epicadvertising.com