<div dir="ltr">Matthias,<br><br>> src/rabbit_amqqueue.erl<br>
> src/rabbit_channel.erl<br>> These should not be required since they are only used by the direct client.<br><ul><li>As the most up to date client code currently stands, amqp_channel calls rabbit_amqqueue in a handle_info function. Although this handle_info function is used only by the direct client, I am uncomfortable with having server-specific code mixed in with pure client code. There should be a clean separation of concerns and all "direct" code, which calls into the server-specific code, should be in one module, and the network-only code in another.</li>
</ul><ul><li>amqp_network_driver calls rabbit_framing_channel, which in turn calls rabbit_channel. So indirectly, the network client uses rabbit_channel and needs it in the common distribution.<br></li></ul><span style="font-family: courier new,monospace;"></span>I wrote a small program that uses xref to compute all the dependencies (transitive closure, I think) of the network client code, after commenting out all code (that I could find, anyway) used for or by the direct driver. This commented-out code needs to be separated so that there is a network client, an orthogonal direct client, and functions in a common app that is used both by clients and the server. I will look into how this can be done cleanly.<br>
<br>The output is as follows (I removed dependencies of test code and direct code modules):<br><br>['$M_EXPR',amqp_channel,amqp_connection,amqp_network_driver,<br> amqp_rpc_client,amqp_rpc_handler,amqp_rpc_util,amqp_util,<br>
dict,gen_event,gen_server,gen_tcp,hessian,io,lists,<br> prim_inet,queue,rabbit_binary_generator,rabbit_framing,<br> rabbit_framing_channel,rabbit_heartbeat,rabbit_misc,<br> rabbit_reader,rabbit_writer]<br><br>So, ignoring modules provided by Erlang/OTP, and the network client modules themselves, the following modules are needed by the network client:<br>
<br>hessian<br>rabbit_binary_generator<br>rabbit_framing<br>rabbit_framing_channel<br>rabbit_heartbeat<br>rabbit_misc<br>rabbit_reader<br>rabbit_writer<br><br>I'd say that would be the basis of a common app.<br><br>Regards,<br>
Edwin<br><br><div class="gmail_quote">On Sun, Sep 7, 2008 at 4:51 AM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@lshift.net" target="_blank">matthias@lshift.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Edwin,<div><br>
<br>
Edwin Fine wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
Bear in mind that the Erlang client code base can operate in both direct and networked mode. For the former you definitely need a server.<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br></div>
The above is on our todo list. Refactoring the code is the easy part. The challenges are in:<br>
<br>
- updating the module structure of the VCS - is rabbitmq_common going to be a separate HG module?<br>
<br>
- figuring out how rabbitmq_common will be distributed. This can be a combination of all of the following: a) separately, b) as part of the Erlang client and server source packages, c) as part of the Erlang client and server binary packages. Then there also the Debian and RPM packages to consider - are we going to have a separate packages for rabbitmq_common or will it be bundled with the existing packages?<br>
<br>
Depending on the above choices a significant amount of work needs to be put into revising the build system, the packaging system, our automated deployment system, the documentation, and parts of the web site.<br>
<br>
That's why it hasn't happened yet.<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Further to my previous email, a minimal list of required modules for<br>
the proposed "rabbit_common" application are listed below (these are<br>
the ones I needed to get things up and running). I am going to make<br>
my own rabbit_common OTP application, and change the Erlang client to<br>
depend on it rather than the server. I will also see what it takes to<br>
change the rabbit 1.4.0 server itself to factor out the common code<br>
and to use this rabbit_common application. Perhaps I can use Dialyzer<br>
to ensure that I get all dependencies. If this would be of interest I<br>
would be glad to share it.<br>
</blockquote>
<br></div>
We definitely appreciate your help in this. Please give the above points some thought. Also, rather than basing your work on 1.4.0, I'd suggest working off the current 'default' branches in hg.<br>
<br>
Some comments on the list of files you came up with:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
src/rabbit_misc.erl<br>
</blockquote>
<br>
This should probably be split into the truly common part, the server part and the client part.<br>
<br>
> include/rabbit.hrl<br>
<br>
Ditto, though this is less important.<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
src/rabbit_amqqueue.erl<br>
</blockquote>
> src/rabbit_channel.erl<br>
<br>
These should not be required since they are only used by the direct client.<br>
<br>
<br>
Regards,<br><font color="#888888">
<br>
Matthias.<br>
<br>
</font></blockquote></div><br></div>