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

Sun Sep 7 09:49:13 BST 2008

Edwin,

On Sun, Sep 7, 2008 at 8:48 AM, Edwin Fine
<rabbitmq-discuss_efine at usa.net> wrote:
> Further to my previous email, a minimal list of required modules for the
> proposed "rabbit_common" application are listed below (these are the ones I
> needed to get things up and running). I am going to make my own
> rabbit_common OTP application, and change the Erlang client to depend on it
> rather than the server. I will also see what it takes to change the rabbit
> 1.4.0 server itself to factor out the common code and to use this
> rabbit_common application. Perhaps I can use Dialyzer to ensure that I get
> all dependencies. If this would be of interest I would be glad to share it.

This would of great value. As indicated in my previous mail, we should
promote the client, so this refactoring work should go into the core
build and release process. Because of the centrality of this work, we
may need to consider effects that it would have on the core process.
The various parts of Rabbit have already been broken out into separate
hg repos, which for practical purposes, need to be checked to sibling
directories in order for the build to work (e.g. rabbitmq-server
expects rabbitmq-codegen to be checked out into the same parent
directory). This approach could be taken for a common Erlang module.

The other consideration that you might make is how this patch gets
played back to the Rabbit dev team. You could generate a simple patch
or you could use hg as a DVCS. One consideration with the latter is
that we use named branches for each new feature or bug. If you were
just to clone and implement this in the default branch of your repo,
we may need to think about how to handle the history (because hg
doesn't rewrite it in the same way that git does).

But having said that I don't want to let any formalities get in the
way of you contributing to Rabbit, so at the end of the day, I would
do what is most convenient for you.

> src/rabbit_binary_generator.erl
> src/rabbit_misc.erl
> src/rabbit_heartbeat.erl
> src/rabbit_reader.erl
> src/rabbit_framing_channel.erl
> src/rabbit_writer.erl
> src/rabbit_amqqueue.erl
> src/rabbit_framing.erl
> src/rabbit_binary_parser.erl
> src/rabbit_channel.erl
> include/rabbit_framing.hrl
> include/rabbit_framing_spec.hrl
> include/rabbit.hrl

Apart from rabbit_amqqueue and rabbitmq_misc, all of those modules
were designed to be eventually sharable, so that is fine.

My gut feeling is that rabbit_amqqueue and rabbitmq_misc are purely
server side concerns and if there is a dependency there, we should
look at it and potentially factor it out.

Cheers,

Ben