[rabbitmq-discuss] [BUG] Erlang RabbitMQ client requires installed server code
Edwin Fine
rabbitmq-discuss_efine at usa.net
Mon Sep 8 00:47:59 BST 2008
On Sun, Sep 7, 2008 at 7:41 PM, Ben Hood <0x6e6562 at gmail.com> wrote:
> Edwin,
>
> On Sun, Sep 7, 2008 at 10:32 PM, Edwin Fine
> <rabbitmq-discuss_efine at usa.net> wrote:
> >
> > 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.
>
> The clean separation has been accomplished by having both modes of
> operation (embedded vs TCP) implemented in separate driver modules.
>
> So if you want to build a network only package, you can just leave out
> the amqp_direct_driver module.
>
> Hence with all due respect, I would disagree that concerns have been mixed.
With all due respect in return, check out this code from
amqp_connection.erl:
%% Starts a new network channel.
handle_call({network, ChannelNumber, OutOfBand}, From, State) ->
handle_start({ChannelNumber, OutOfBand},
fun amqp_network_driver:open_channel/3,
fun amqp_network_driver:close_channel/1,
fun amqp_network_driver:do/2,
fun amqp_network_driver:do/3,
State);
%% Starts a new direct channel.
handle_call({direct, ChannelNumber, OutOfBand}, From, State) ->
handle_start({ChannelNumber, OutOfBand},
fun amqp_direct_driver:open_channel/3,
fun amqp_direct_driver:close_channel/1,
fun amqp_direct_driver:do/2,
fun amqp_direct_driver:do/3,
State);
This ties the module to amqp_direct_driver by naming it. xref will show this
code is dependent on amqp_direct_driver. Dialyzer will complain if
amqp_direct_driver is not there. This call should be handled somewhere else.
In my humble opinion.
>
>
> > 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.
>
> This is true, but this only pertains to the do/2 and do/3 calls, which
> *could* be abstracted out of the rabbit_channel module with not too
> many changes.
Well, then, let's factor it out.
> > So, ignoring modules provided by Erlang/OTP, and the network client
> modules
> > themselves, the following modules are needed by the network client:
> >
> > hessian
>
> I have just deleted the reference to hessian (bug19334). This was
> something experimental and should not be in the client code base.
Ok, good to know!
> > rabbit_binary_generator
> > rabbit_framing
> > rabbit_framing_channel
> > rabbit_heartbeat
> > rabbit_misc
> > rabbit_reader
> > rabbit_writer
>
> Ben
>
Regards,
Edwin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080907/3b26d973/attachment.htm
More information about the rabbitmq-discuss
mailing list