[rabbitmq-discuss] [BUG] Erlang RabbitMQ client requires installed server code
Edwin Fine
rabbitmq-discuss_efine at usa.net
Mon Sep 8 01:06:48 BST 2008
Our emails crossed in the ether :)
On Sun, Sep 7, 2008 at 8:03 PM, Ben Hood <0x6e6562 at gmail.com> wrote:
> On Mon, Sep 8, 2008 at 12:47 AM, Edwin Fine
> <rabbitmq-discuss_efine at usa.net> wrote:
>
> > 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.
>
> I was just thinking back to an earlier version of the client that used
> parameterized modules to solve this dependency. Maybe that could an
> option. Or perhaps by defining a new OTP behavior?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080907/8818b3ae/attachment.htm
More information about the rabbitmq-discuss
mailing list