[rabbitmq-discuss] [BUG] Erlang RabbitMQ client requires installed server code

[Ben Hood]

Hi Edwin,

On Sun, Sep 7, 2008 at 7:56 AM, Edwin Fine
<rabbitmq-discuss_efine at usa.net> wrote:
> I had a surprise when trying to use the Erlang client on a node on which
> RabbitMQ Server was not installed.

Opening up this discussion on a friendly note :-) , the README does
state that you need to install the Rabbit server for the client.

> A network client should not require server code to be installed on the same
> node. This is certainly true of other clients I have used.
>
> On further investigation, I found a number of direct calls and references to
> an installed server:

This is code reuse :-)

A number of design considerations went into the Erlang client:

- Reuse the codec handling facilities that were already implemented in
the server;
- Implement a plain jane TCP based AMQP wire client in Erlang using
the principles that were known to work from the server;
- Provide a an embedded client that offers the same AMQP based API as
the TCP based client - effectively swap out networking and codec
marshalling for sending native Erlang messages, but keep it
transparent to the client. The use case for this is for colocated
client applications for efficiencies' sake that are not dependent on
the native Rabbit API, which could change over time.

To implement the third point, we had to generalize the channel concept
in the server to provide a coarse grained interface that allows the
client to implemented as an inversion of the server.

The approach that was taken for the direct client was also taken for
the TCP client, in order to keep things consistent and to benefit from
proven design principles.

Also, from a maintainance perspective, there are a lot of benefits
from re-using tested server code.

Hence you will notice many dependencies on the server code base.

> amqp_channel.erl:-include_lib("rabbitmq_server/include/rabbit_framing.hrl").
> amqp_util.erl:-include_lib("rabbitmq_server/include/rabbit_framing.hrl").
.......
> I left out the direct driver modules because by definition they need to be
> on the same node.

True.

> I respectfully suggest that the above RabbitMQ server modules, and their
> dependencies, be bundled with the Erlang client. Ideally, I would think it
> would be best perhaps to put them a separate Erlang library application
> (maybe "rabbitmq_common") that is used both by the server and the Erlang
> client.

When suggesting this, you don't have to be respect, because it is
obviously a very good idea :-)

In fact, when we wrote the first version of the client, we did think
about breaking out the commonalities between the server and the client
into a separate common module. We didn't go down that route to begin
with because we wanted to see how the client would work and to get
feedback from people using it. We thought it would be a better idea to
get the code out in a usable state rather than put lots of effort into
packaging something that people may not even want to use.

However, now it has become apparent that there is interest in a client
for Erlang, so it is now time to promote the client's status from
experimental to an officially supported package. This should include
proper packaging, documentation and the resolution of some minor
outstanding issues.

> In addition to that, the include_lib("rabbitmq_server/include/xxx.hrl")
> statements prevent one from even compiling the client unless the server is
> installed and this should be changed to use the common library app. I was
> forced to copy the include files and make a dummy rabbitmq_server
> application to be able to compile the client on a different node to the
> server.

Yes, this is a drawback. I see you've written a follow up mail, so I
will go into more details when replying to that.

Ben